Category Archives: sqlmap

I’m a novice InfoSec student conducting research on the SQL injection vulnerabilities present in FAQ package 2.x before 2.3.6, 4.x before 4.0.5, and 5.x before 5.0.5 in Open Ticket Request System (OTRS) which allow remote attackers to execute arbitrary SQL commands via crafted search parameters (CVE-2016-5843).

The details of this vulnerability, as advertised on multiple security advisories such as SecurityTracker, seem to suggest that unauthenticated attackers can execute arbitrary code on the underlying SQL database via [OTRS_BaseURI]/index.pl?Action=Login&User=%27[SQL_HERE] to bypass authentication procedures.

SQL injection is definitely one of the weaker tools in my arsenal, so I would truly appreciate some guidance in this regard.

I have taken steps to determine appropriate attack vectors, but so far none have proven fruitful. In addition to manually fuzzing the entry point above, I’ve also utilised various command-line configurations of sqlmap to detect injection flaws—no luck.

So, I proceeded to inspect the source code, and found what appears to be the user validation query.

# sql query
my $SQL = "SELECT $Self->{UserTableUserPW}, $Self->{UserTableUserID}, $Self->{UserTableUser} "
    . " FROM "
    . " $Self->{UserTable} "
    . " WHERE "
    . " valid_id IN ( ${\(join ', ', $Kernel::OM->Get('Kernel::System::Valid')->ValidIDsGet())} ) AND "
    . " $Self->{UserTableUser} = '" . $DBObject->Quote($User) . "'";
$DBObject->Prepare( SQL => $SQL );

This snippet resides in otrs-5.0.2/Kernel/System/Auth/DB.pm of the otrs-5.0.2 package.

I’m not too familiar with Perl, but it seems the $User parameter is double quoted before being passed to the database. Curiously enough, the other SQL queries I found in this package used “?” placeholders instead.

=item Quote()

to quote sql parameters

quote strings, date and time:
=============================
my $DBString = $DBObject->Quote( "This isn't a problem!" );

my $DBString = $DBObject->Quote( "2005-10-27 20:15:01" );

quote integers:
===============
my $DBString = $DBObject->Quote( 1234, 'Integer' );

quote numbers (e. g. 1, 1.4, 42342.23424):
==========================================
my $DBString = $DBObject->Quote( 1234, 'Number' );

=cut

sub Quote {
    my ( $Self, $Text, $Type ) = @_;

    # return undef if undef
    return if !defined $Text;

    # quote strings
    if ( !defined $Type ) {
        return ${ $Self->{Backend}->Quote( \$Text ) };
    }

    # quote integers
    if ( $Type eq 'Integer' ) {
        if ( $Text !~ m{\A [+-]? \d{1,16} \z}xms ) {
            $Kernel::OM->Get('Kernel::System::Log')->Log(
                Caller   => 1,
                Priority => 'error',
                Message  => "Invalid integer in query '$Text'!",
            );
            return;
        }
        return $Text;
    }

    # quote numbers
    if ( $Type eq 'Number' ) {
        if ( $Text !~ m{ \A [+-]? \d{1,20} (?:\.\d{1,20})? \z}xms ) {
            $Kernel::OM->Get('Kernel::System::Log')->Log(
                Caller   => 1,
                Priority => 'error',
                Message  => "Invalid number in query '$Text'!",
            );
            return;
        }
        return $Text;
    }

    # quote like strings
    if ( $Type eq 'Like' ) {
        return ${ $Self->{Backend}->Quote( \$Text, $Type ) };
    }

    $Kernel::OM->Get('Kernel::System::Log')->Log(
        Caller   => 1,
        Priority => 'error',
        Message  => "Invalid quote type '$Type'!",
    );

    return;
}

Taking these snippets into consideration, my questions are:

1. Is the login form vulnerable to SQL injection?
2. If indeed it is, why can’t I seem to execute arbitrary code?
3. How would one go about compromising a Linux box with this specific vulnerability?

Continue reading CVE-2016-5843 SQL injection in Open Ticket Request System (OTRS) 5.x→