If you want to extract some data from a database you first need to gather
knowledge about the internal structure of the database.
One of the first steps (after determining the database type) is enumerating the
available tables and the corresponding columns. Most database systems have a
meta database called information_schema. By querying this database it is
possible to get information about the internal structure of the installed
databases. For example you could get the tables and their corresponding columns
in MS SQL and MySQL by injecting
“SELECT table_name, column_name FROM information_schema.columns“. Oracle
databases have their own meta tables, so you have to handle them differently.
For getting the same output in Oracle, you have to query the all_tab_columns
table (or user_tab_columns if you only want to search in the currently selected
database). If the found vulnerability only allows to receive a single column (or
if it is too complicated to identify two columns in the server response) you
could concatenate the columns to one single string, e.g. in Oracle:
“SELECT table_name||':'||column_name FROM all_tab_columns“.
There are some database specifics, every pentester should be aware of, when
testing for and exploiting SQLi vulnerabilities. Besides the different string
concatenation variants already covered above, there are some other specifics
that have to be considered and might turn out useful in some circumstances. For
example with Oracle Databases, every SELECT statement needs a following FROM
statement even if the desired data is not stored within a database. So when
trying to extract e.g. the DB username using a UNION SELECT statement, the DUAL
table may be utilized, which should always be available. Another point, if
dealing with MySQL, is the possibility to simplify the classic payload
SQL injection attacks have been well known for a long time and many people think
that developers should have fixed these issues years ago, but doing web
application pentests almost all the time, we have a slightly different view.
Many SQL injection problems potentially remain undetecteddue to a lack of
proper test methodology, so we would like to share our approach and experience
and help others in identifying these issues.
In march 2012 Microsoft announced a critical vulnerability
(Microsoft Security Bulletin MS12-020)
related to RDP that affects all windows operating systems and allows remote code
execution. A lot of security professionals are expecting almost the same impact
as with MS08-067 (the conficker vulnerability) and that it will be only a matter
of time, until we will spot reliable exploits in the wild. Only a few days later
an exploit, working for all unpatched windows versions was released, so it seems
that they were right ;-), but of course no one will run an exploit without
investigating the code. So lets have a look into the exploit Code.
Some days ago a security advisory related to web application firewalls (WAFs)
was published on Full Disclosure. Wendel Guglielmetti Henrique found another bug
in the IBM Web Application Firewall which can be used to circumvent the WAF and
execute typical web application attacks like SQL injection (click
here
for details). Wendel talked already (look
here)
at the Troopers Conference in 2009 about the different
techniques to identify and bypass WAFs, so this kind of bypass methods are not
quite new.
Some days ago a security advisory related to web application firewalls (WAFs)
was published on Full Disclosure. Wendel Guglielmetti Henrique found another bug
in the IBM Web Application Firewall which can be used to circumvent the WAF and
execute typical web application attacks like SQL injection (click here for
details). Wendel talked already (look
here)
at the Troopers Conference in 2009 about the different
techniques to identify and bypass WAFs, so this kind of bypass methods are not
quite new.
After the initial quick shot (see this
post)
we decided to have a closer look. And some more stuff turned up.
After decompiling the integrated java stuff we stumbled about hard coded server
credentials:
package Idonttell;
public abstract interface Idonttell { public static final boolean debug = false; public static final boolean auth = true; public static final String SMTP_SERVER = "Idonttell.openlimit.com"; public static final String SMTP_USER = "Idonttell@Idonttell.openlimit.com"; public static final String SMTP_PASSWORD = "Idonttell"; public static final String SEND_FROM = "Idonttell@Idonttell.openlimit.com"; public static final String[] SEND_TO = { "buergerclient.it-solutions@Idonttell.com" }; public static final String MAIL_HEADER_FIELD = "OpenLimitErrorMessage"; public static final String MAIL_HEADER_FIELD_PROP = "yes"; }
Currently there’s quite some discussion about the security properties and
posture of the German new ID card (“Neuer Personalausweis”, “nPA”, some
technically reasonable security discussion can here be found e.g.
here.
While – as of our current knowledge – we do not expect major security flaws on
the architecture level, the problems discussed so far (like
Evilgrade
style attacks against one of the main applications or keylogging the PIN in
scenarios with
pinpad-less readers
) certainly show that security best practices must be followed by all parties
involved in the development, deployment and use of the nPA and it’s associated
applications. From our perspective this may be expected from the applications’
developers as well.
Looking at this:
Finding exploitable vulnerabilities is getting harder. This statement of Dennis
Fisher published on
Kaspersky’s Threatpost blog
summarizes a trend in the development lifecycle of software . The last published
vulnerabilities that were gaining some attention in the public had all one thing
in common, they were quite hard to exploit. The so called jailbreakme
vulnerability was based on several different vulnerabilities that had to be
chained together to break out of the iPhone sandbox, escalate its privileges and
run arbitrary code. Modern software and especially modern operating systems are
more secure, they contain less software flaws and more protection features that
make reliable exploitation a big problem that can only be solved by very skilled
hackers. Decades ago it was just like this, but intelligent tools and sharing of
the needed knowledge enabled even low skilled people to develop working exploits
and attack vulnerable systems. Nowadays we are going back to the roots where
only a few very knowledgeable people are able to circumvent modern security
controls, but that doesn’t mean that all problems are gone. Attackers are moving
to design flaws like the DLL highjacking problem, so only the class of attacks
is changing from the old school memory corruption vulnerabilities to logical
flaws that still can be exploited easily. But the number of exploitable
vulnerabilities is decreasing, so this might be a sign that we are on the right
way to develop reliable and secure systems and that developing companies are
adopting Microsofts Secure Development Lifecycle (SDL) to produce more secure
software. As stated in my previous
blogpost
the protection features are available, but not used very often. But if they are
used and if the developers are strictly following the recommendations of the
SDL, this trend of “harder to exploit vulnerabilities” proves that it can be a
success story to do so.
According to
SANS NewsBites Vol. XII, Issue 53
recently published there’s a lack of 3rd party developer support for some
security features Microsoft introduced already years ago. We at ERNW have made
similar observations when performing security assessments of COTS [commercial
off-the-shelf] software. We therefore created a methodology, a
proof of concept tool
and a metric to test and to rate closed source software, where (amongst other
approaches) these security features are checked and their (non-) presence
contributes to an overall evaluation as for the trustworthiness of the
applications in question. The concept “How to rate the security in closed source
software” was presented to the public at Troopers10
and at Hack in the Box 2010 in Amsterdam.
The slides can be found
here.