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

 

Описание предметной области

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

Система аутентификации стара, как мамонт, и методы ее взлома такие же. Естественно, самый простой способ - это перебор всех возможных вариантов ПИН-кода (предположим, что номер договора/контракта/счета/телефона уже известен), но слабое место этого метода - время, необходимое для перебора множества вариантов. А вот тут начинается самое интересное. Во-первых, ПИН-код является числом, то есть это пароль, в котором используются только цифры, так как через телефонную сеть в тоновом режиме можно передавать только цифры, знак «#» и знак «*». Во-вторых, не знаю почему, ПИН-код у большинства систем составляют четыре цифры. Получается, что, для того чтобы подобрать ПИН-код, достаточно перебрать не
более 10 000 вариантов
. На один ПИН-код уходит примерно 30 сек; соответственно, на перебор 10 000 вариантов потребуется 300 000 сек (или 83,3 часа). Для компьютера это ерунда, а вот для человека будет весьма затруднительно. Более того, автоинформатор специально создавался для ручного ввода. Но если попытаться автоматизировать процесс работы с автоинформатором, то ситуацию можно исправить.

Автоматизировать процесс передачи логина и ПИН-кода в тоновом режиме не проблема, это умеет любой модем (voice-модемы могут даже распознавать такие данные). Но вот получить ответ гораздо сложнее, так как ответ о правильности/неправильности пароля дает непосредственно сама «железная тетка». Вот теперь обратная ситуация: человек поймет, о чем говорит «железная тетка», а для компьютера это будет некоторой проблемой. Несмотря на то что «тетка» «железная», говорит она человеческим голосом, соответственно, здесь необходима некоторая система распознавания речи.

Итак, думаю, ты вник в предметную область, теперь давай я сформулирую цель и задачи, которые преследовал конкретно я. Цель: получить логин и пароль для одной забугорной системы, работающей на основе голосового меню.

 

Задачи

  1. реализовать цикл перебора пароля;
  2. реализовать модуль передачи данных в телефонную сеть в виде DTMF-сигналов;
  3. реализовать модуль приема ответа в виде голосового сообщения;
  4. реализовать модуль распознавания ответа.

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

Но для себя я решил эту задачу несколько иным образом, как мне кажется, более простым. В качестве посредника при доступе в телефонную сеть я использовал Skype. Он подошел мне по двум причинам. Во-первых, он имеет очень простой программный интерфейс, позволяющий решить все проблемы с генерацией DTMF и оцифровкой. Во-вторых, Skype мог позволить мне сэкономить на международных звонках, поскольку я «работал» с одним очень далеким американским голосовым сервисом :). Skype позволяет записать разговор в виде WAV-файла, соответственно, четвертый модуль будет представлен в виде функции сравнения двух файлов, но к этому мы еще вернемся (это самый интересный модуль). Общая схема моего брутфорсера
представлена на рисунке.

 

Модуль связи с Skype

Ты, наверное, уже сталкивался с программой Skype. Помимо того что эта программа является интернет-телефоном, она также представляет собой некоторый сервер с командным интерфейсом на борту (Skype API) для управления внутренними функциями (управление звонками, сообщениями, видеоконференциями и т.д.). Для приложений Win32 в Skype имеется два способа передачи команд. Первый способ основан на системе оконных сообщений, то есть программа может отправлять команды, используя сообщения WM_COPYDATA. Сначала программа отправляет широковещательное сообщение всем окнам и получает ответ от Skype, затем отправляется сообщение WM_COPYDATA и в
параметре LPARAM передается сама команда для Skype. Второй способ предполагает использование COM-объекта Skype4COM, который предоставляет Skype API в виде некоторого интерфейса. Но в этом случае необходимо еще скачать файл Skype4Com.dll, который и является этим интерфейсом.

Я писал свой брутфорсер на C#, поэтому мне было удобнее задействовать второй способ. Для отправки DTMF-сигналов я использовал команду SET CALL DTMF <value>, где value - один из символов 0-9, «#», «*». Для оцифровки ответа - команду ALTER CALL <id> SET_OUTPUT FILE=”FILE_LOCATION”, где id - идентификатор сеанса связи (их может быть несколько), FILE_LOCATION - имя файла, в который будет записываться весь звуковой поток (WAV PCM, 16 кГц моно, 16 бит). Проще говоря, я перенаправлял выходной звуковой поток в WAV-файл. Также звуковой поток можно перенаправить на звуковую карту или локальный TCP-порт. Как создать или прервать сеанс связи (ну, в смысле дозвониться), я думаю, ты уже разобрался.

 

Модуль распознавания ответа

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

В принципе, его можно создать и без непосредственного распознавания, ведь, прослушав сообщение о результате аутентификации, сделать вывод о том, какая фраза была произнесена, можно по его длине, поскольку после ПИН-кода возможно два сообщения: либо ответ «Да», либо ответ «Нет». Но при таком подходе возникает проблема.

Как видно из схемы, суммарное время, затраченное на один вариант, составляет 52-66 сек. Перебор 10 000 вариантов может занять до 183 часов, причем это время будет затрачено на подбор пароля для одного логина. Приветствие, ответ и подтверждение логина можно сократить без последствий (если сервисное меню позволяет это). А вот сообщение результата аутентификации сократить нельзя, поскольку тогда невозможно будет распознать тип ответа.

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

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

На наш взгляд, оба файла одинаковы, но для программы это абсолютно разные файлы, они даже по размеру отличаются друг от друга на несколько сотен байт. Поэтому, совпадает ли эталонное значение с записанным, сказать однозначно нельзя. Но можно оценить степень их схожести в процентах. Назовем эту оценку ошибкой. Чем больше ошибка, тем менее схожесть файлов. Для принятия решения о совпадении эталона и записи указываем пороговое значение ошибки. Оценка производится очень просто: рассчитываю в процентах, насколько каждый байт эталона отличается от соответствующего записанного байта, и нахожу среднее значение процента ошибки. Но если оценивать оба файла напрямую, то даже для представленного
примера ошибка будет очень большой. Поэтому, перед тем как производить оценку, я подготавливаю оба файла, то есть делаю нормализацию (масштабирую по высоте), обрезаю паузы в начале и конце каждого файла, затем осуществляю аппроксимацию и сжатие до 100 значений. В результате получаю два массива данных по 100 значений (смотри рисунок), которые необходимо сравнить. Для показанного примера ошибка составляет 25%, но не стоит забывать, что это относительное значение, поэтому его надо сравнить с пороговым значением ошибки. А вот пороговое значение я определял экспериментально.

 

Брутфорсер

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

  1. «Анализ» - отображает процесс работы брутфорсера;
  2. «Настройки» - все основные настройки;
  3. «Сравнение» - оценка двух произвольных WAV-файлов.

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

 

Выводы

Ну и немного о результатах практического применения брутфорсера. В результате всех действий мне удалось сократить время, затрачиваемое на обработку одного варианта, до 30 сек., и недельная работа брутфорсера принесла 12 логинов с ПИН-кодами и немалый счет за телефонные звонки по Skype (никто не говорил, что это бесплатно). Но в моем случае шкурка стоила выделки, поскольку в конечном итоге вернулась в двадцатикратно большем размере (но это уже совсем другая история).

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


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

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

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

    Подписаться

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