Local root attack

Наверное, можно точно сказать, что атаки на получение прав root или Administrator гораздо более опасны, так как атакующий получает полный доступ к машине, и может сделать всё что угодно – начиная от возможного удаления данных и заканчивая так называемой компрометацией системы (проведение других атак с этой машины). Здесь также есть деление на локальное и удалённое получение необходимых прав.

Начнём, пожалуй, с локального варианта, так как зачастую он наиболее легко реализуем. Связанно это с тем, что при локальном доступе у пользователя гораздо больше возможностей найти «дырявую» программу. А далее – всё то же самое, что и описывалось ранее для удалённых атак на отказ в обслуживании – наиболее любимым способом заставлять программу делать не то, что ей «положено», является выход за пределы отведенного буфера. В том случае если программа имеет так называемый SIUD-бит, и если пользователь вообще имеет право на запуск этой программы, то её запуск произойдет от лица суперпользователя. Эти программы являются наиболее «лакомым» кусочком для поиска дырок. Существует же, однако, и другой род программ, дающих права суперпользователя – те, которые уже работают при запуске системы, и которым «по работе» необходим доступ к любому месту операционной системы. Например, это может быть почтовый демон. И алгоритм работы здесь точно такой же – переполнение буфера.

Впрочем, в работе локально добавляются ещё и другие прелести жизни – эта атака использует небезопасное создание временных файлов. Для лучшего понимания опять таки рассмотрим пример: пусть существует база данных, которая во время запуска создаёт временный файл /tmp/NameOfFile.some_addition. Зачастую все, что находится до точки – не изменяется от запуска к запуску, а вот то, что после точки – должно быть всё время и, что немаловажно, уникальным. Наша программа будет иметь SUID-бит и создавать временный файл по следующей схеме – /tmp/ NameOfFile.PID, где PID – это, соответственно, номер процесса. Вполне возможно, что такой файл будет уни кальным, однако его имя будет предсказуемо, и в этом заключается главная ошибка. Директория /tmp обычно разрешает запись в неё любых файлов, любого пользователя, и потому можно создать символическую ссылку на файл, который нужно переписать, но который имеет «недостижимые» для нас права доступа. Кроме того, пусть наша база данных записывает в файл аргументы, с которыми она была вызвана. Тогда делаем просто – создаём ссылку, скажем, с /etc/passwd на /tmp/NameOfFile.Guesed_PID. Далее вызываем нашу базу данных с параметрами root::0:0:root:/root:/bin/sh. Допустим, по причине неправильных аргументов программа завершается, но что оказывается в файле /etc/passwd? Правильно – наша запись, которая позволяет заходить любому пользователю в качестве суперпользователя без пароля. Кстати, неплохо было бы сделать копию переписываемого файла, чтобы не было сильно заметно, что что-то произошло (благо /etc/passwd читаем любым пользователем). Вот и все.