что делает strcpy

Это говорит нам о том, что для вызова фун

Видно, что есть путь до функции vuln (и, как следствие, до strcpy) от публичного метода класса ImportKey(). На самом деле почти все методы класса пытаются что-то писать в лог, поэтому такой путь есть от многих:

Как таковой уязвимости тут нет. Она есть дальше, в функции обработки ошибки при создании лог-файла (назовем ее vuln). Эта функция вызывается в том случае, если LogEnabled > 0, LogFileName задан, и при этом файл с логом создать не удалось. Для составления вектора эксплуатации нужно проследить путь до этой функции. Впрочем, в IDA 6.2 это сделать крайне просто: Proximity browser + Find Path. Этот функционал помогает найти путь между любыми вызовами, если он есть. Например, так:

Все эти вызовы можно проанализировать также в IDA (параллельно можно также использовать отладчик, например Immunity Debugger, с целью более быстрого понимания ситуации и для анализа динамических вызовов). Сквозь неопределенное время анализа кода и некоторого количества запусков в отладчике было выявлено, что часть функционала фаззер просто ПРОПУСТИЛ, так как были явные проверки на значение других свойств метода. То есть фаззер анализировал все методы и свойства отдельно, и потому часть кода была просто не покрыта (ох уж этот дамб-фаззинг). Так, например, свойство LogFileName задавало имя файла логов. А это имя хранится в специальном буфере и используется при вызове ДРУГИХ методов, которые порождают записи в лог. Тогда как фаззер просто пытался делать так:

Однако по этому поводу были сомнения. Все же DLL ка с кодом датирована аж 2006 годом. Загрузив библиотеку в IDA и бросив беглый взгляд на количество вызовов такой знаменитой функции, как strcpy, я почти не удивился. Все это как бы намекало на то, что уязвимости все же есть.

Классикой жанра при поиске дырок является, безусловно, фаззинг. Для того чтобы «профаззить» данное ПО, можно воспользоваться, например, известной тулзой COMRaider. Как ей пользоваться, я в журнале «Хакер». Суть технологии проста: все методы и свойства ActiveX-класса вызываются с различными параметрами, например, с длинными строками или строками с вставленными спецификаторами формата. И в случае если есть ошибка, например, переполнение буфера при обработке длинной строки, то регистрируется исключительная ситуация (приложение попросту валится). Но вот незадача: выполнив фаззинг, COMRaider не обнаружил ни одной исключительной ситуации, ни одной уязвимости все прошло без проблем. Ура, дырок нет!

Поиск уязвимости

Компонент установлен, отлично. Однако хочется отметить, что данный модуль мог быть активирован только с домена банка, а это значит, что для эксплуатации уязвимостей этого модуля необходимо либо использовать баги типа XSS, либо быть «человеком посередине». Это сильно уменьшает вероятность атаки, но не делает ее нереальной.

Пользователи системы «интернет-банк» получают «довесок» в виде компонента ActiveX. Данное ПО отвечает за работу с ЭЦП, с документами и т.д. Написано оно, как правило, на С или С++. А это означает, что такие вещи, как ошибки формата строки, переполнения буфера или ошибки при работе с указателями, вполне себе характерны для этого вида ПО. Исследуемый компонент ставился автоматически для всех клиентов, которые хотели работать с сертификатами, прямо со специальной веб-страницы:

Сама была обнаружена и сразу же исправлена в 2010 году. Поэтому никакого вреда от этого поста никому не будет, только уроком 8)

ПОЧТИ все уязвимости, о которых шла речь, на данный момент исправлены. Уязвимость, о которой идет речь конкретно в данном посте исправлена давным-давно. Этот производитель СДБО выбран в качестве «жертвы» данного поста именно потому, что у него единая точка входа, а значит достаточно обновить ActiveX в одном месте. С другими производителями сложнее, так как надо обновлять КАЖДЫЙ банк ОТДЕЛЬНО и независимо, поэтому есть вероятность, что даже для старых уязвимостей в BSS/Inist/R-Style, существуют инсталляции без установленного обновления.

Последнее время многие обращают внимание на уязвимости ПО, используемого в банковском секторе: в частности, недавно прошумела новость об уязвимостях класса XSS на веб-сайтах различных банков. Общественность негодует, и СМИ шумят. Но ведь банки богаты не только веб-составляющей. Начиная с конца 2000-х я собирал уязвимости в модулях ActiveX, которые банки гордо раздают своим пользователям, а именно клиентам системы дистанционного банковского обслуживания (ДБО). Раз в год я брал одну или две системы и ковырял их. Начиная просто так, любопытства ради (начал это дело, еще будучи сотрудником банка) и продолжая уже из . В итоге за 3 4 года я выявил уязвимости в системах от таких производителей, как BSS, Inist, R-Style, ЦФТ. Под катом находится информация об одной такой уязвимости. Большая часть описания уделена созданию простенького эксплойта для выполнения произвольного кода на стороне клиента (Windows7, IE +DEP/ASLR). Возможно, это будет полезно тем, кто хотел бы понять принципы эксплуатации старых strcpy багов и создания ROP-эксплойтов.

Ломаем банк в стиле smash the stack!

Ломаем банк в стиле smash the stack! / Блог компании Digital Security / Хабрахабр