Comments 101
Вознаграждение было?
Нет
В нашей реальности можно радоваться, что не «догнали и еще раз не вознаградили»… =( Не так давно была статья, что за аналогичное сообщение в банк автора выставили, как злоумышленника, вместо спасибо. Так что не удивлюсь.
Там сам человек был немного не прав, он для демонстрации уязвимости списал приличную сумму со случайного клиента, потому банк и засуетился, так как это чревато судебными исками от клиента. А списал бы с карты родственника/друга и сумму поменьше, проблем бы не возникло.
А разве самого факта неавторизированного доступа к закрытой информации не является поводом для судебного разбирательства?
В данном случае информация оказалось открытой. Да и человек сообщил о найденной уязвимости в альфа банк, что бы они устранили её и настоящие злоумышленники не могли пользоваться дырой.
Это по-житейски всё так, как Вы пишете. А по букве закона человек не имел права ковырять эту уязвимость на других клиентах и его можно наказать. Можно, конечно, строить защиту на «отсутствии умысла преступления», не знаю, насколько это было бы эффективно. Так что хорошо, что банк не обиделся.
Как-то довелось пообщаться на эту тему с бывшим сотрудником it-безопасности IBM.
Так вот он однозначно сказал: «Нашел уязвимость — молодец, но не сообщай об этом никуда и никому.»
Потому что, даже если тебе скажут спасибо, ты уже будешь в списке будущих возможных подозреваемых.
Так вот он однозначно сказал: «Нашел уязвимость — молодец, но не сообщай об этом никуда и никому.»
Потому что, даже если тебе скажут спасибо, ты уже будешь в списке будущих возможных подозреваемых.
Я давным давно общался с сотрудником IBM, который отвечал за ТП в EMEA (в частности OSS/BSS) и задавал практически аналогичный вопрос. Может ли партнер компании IBM, который расковырял ошибку в ПО IBM не совсем «правильным» способом (например декомпилировав java) сообщить ТП где ошибка в коде, чтобы максимально быстро миновать 1ю и 2ю линию. Ответ был аналогичным — не стоит, так как лицензионное соглашение это запрещает (именно в связи с этим и был задан вопрос)
Из своего опыта — какое вознаграждение? Хорошо что в суд не подали.
Звякнем ему?
— Звякнем ему?
— О, Боже. Зачем?
Он захочет быть уверен, что его херня в безопасности.
Он-он-он он успокоится.
Может, он настолько успокоится, что даст нам награду.
Я буду чертовски удивлён, если нет.
Очень удивлён.
Типа, налог добрых самаритян.
Который вовсе и не налог, раз он добровольный.
— О, Боже. Зачем?
Он захочет быть уверен, что его херня в безопасности.
Он-он-он он успокоится.
Может, он настолько успокоится, что даст нам награду.
Я буду чертовски удивлён, если нет.
Очень удивлён.
Типа, налог добрых самаритян.
Который вовсе и не налог, раз он добровольный.
сложновато с проксисервером и iOS
почему не раздать wifi и не смотреть Wireshark?
почему не раздать wifi и не смотреть Wireshark?
Современные крупные организации моментально отвечают в твиттере. Особенно, альфа-банк. Решал через них много проблем, достаточно упомянуть @alfa_bank.
Тогда, по логике, сейчас мы ждём сюда в гости их пиарщика благодарить dinikin и вручать символическое, но очень важное вознаграждение. Потому что следующий раз он может не сообщить в банк (два раза, пробившись ещё и через колл-центр), а тупо продать уязвимость налево. Там ей точно заинтересуются больше )
Как вы себе представляете выделение денег на bug bounty в большой организации, если такой программы у них нет? Такие вещи нужно планировать на кварталы вперед и утверждать по всем инстанциям.
Я боюсь, что никаких денег пиарщики альфабанка не принесут, но большое спасибо скажут.
Конечно, это неправильно и так быть не должно. Но большие организации работать по-другому обычно не умеют.
Я боюсь, что никаких денег пиарщики альфабанка не принесут, но большое спасибо скажут.
Конечно, это неправильно и так быть не должно. Но большие организации работать по-другому обычно не умеют.
Могут «отдать натурой», мне кажется. Ну, всмысле, какие-то льготы/скидки на обслуживание дать.
Всегда есть сувенирная, раздаточная продукция. Я думаю, одних сувениров можно несколько коллекций собрать. Найдут, что подарить, если поднапрягутся.
уж если учитывать что у них пользование приложением стоит отдельных денег, не особо понятно почему нет вообще никакой фин.обеспеченности таких вот случаев
нет, не стоит. ну, во всяком случае у меня его бесплатно к карте подключили и нигде я не видел прайсов)
Вообще-то мы оба правы, зависит от тарифа. Но на большинстве тарифов все же стоит отдельных денег.
1. Всегда есть оперативный резерв. Если вы хоть раз делали квартальное планирование, то прекрасно знаете, что не вкладывать строчку «непредвиденные расходы» — утончённый вид стрельбы себе в ногу.
2. И бюджет PR. Который после моего упоминания переходит именно туда )
2. И бюджет PR. Который после моего упоминания переходит именно туда )
с зарплаты программистов, премию убрать :)
Легко и просто. Руководитель службы безопасности на личном лексусе или мерседесе(на чем он там ездит)заехал и купил бутылку коньяка. Передал лично. Так делают нормальные люди, а в большой конторе работают эти люди или в маленькой это уже вопрос номер два. Может возникнуть проблема если руководитель в одном городе а человечек в другом, но я думаю, это тоже можно решить.
а они в свитере и ответили
"Asgoret В статье речь об украинском Альфа-Банке, поэтому не можем прокомментировать."
В общем, у них там свой альфа-банк, с приложениями и банкомётами.
"Asgoret В статье речь об украинском Альфа-Банке, поэтому не можем прокомментировать."
В общем, у них там свой альфа-банк, с приложениями и банкомётами.
UFO just landed and posted this here
Альфа вроде бы есть на хабре, стоит их сюда позвать Biofer Fireblade59 HighExceL Maxim_Azrilyan NoGotnu OrionDim Reijii RenegadeMS RockBee ZTamara catlion glar malstoun nizamovich nmouse romaromk rvller verybigman Что бы они дали свой комментарий и объяснили почему не решили его денежно вознаградить. (Могли хотя бы gold карту дать...)
Да и так платиним дают визу… чо толку-то с неё?) Даже в интернет не расплатишься… А ещё этот самый «мы вам готовы дать кредитку с лимитом в 1 лям и без процентов на 100 дней» — ну и кому эт надо по-сути, когда у тебя на «моём сейфе» лежит 10+М?.. Короче хрень это всё. Чтобы денежно вознаградить надо чтобы был бюджет. Сейчас в альфе не самые лучше времена в части бюджетов…
ЗЫ: мне выписку о состоянии счета (для визы) делали там 30 (!) минут… вот те и альфа.
ЗЫ: мне выписку о состоянии счета (для визы) делали там 30 (!) минут… вот те и альфа.
Судя по тому, что вам удалось так легко перехватить https трафик, сертификат сервера они в приложении тоже не пинят? Ооооок.
Да, именно в этом приложении сертификат они не проверяют, проверял другие их приложения, то в них сервер обрубал коннект на хендшейке
А нафига его пинить? Почему отсутствия сертификата в доверенных не достаточно?
Можете привести пример, когда злоумышленник может подменить данные программы, притом, что вы не устанавливали на телефон левых сертификатов вроде DO_NOT_TRUST_FiddlerRoot?
Можете привести пример, когда злоумышленник может подменить данные программы, притом, что вы не устанавливали на телефон левых сертификатов вроде DO_NOT_TRUST_FiddlerRoot?
ПО, особенно банковское, оно как колбаса и политика, если они вам нравятся то лучше не знать как они делаются.
Есть возможность получать выписки клиентов одной конторы. Связывался со службой безопасности, объяснял им все, что они плохо обезличивают данные клиента. Похоже меня не поняли. Единственный способ — собрать некоторые выписки и показать. Но я опасаюсь это делать, хотя уже получил несколько штук, потому что меня обвинят в проникновение в систему.
Да, чужие персональные данные публиковать не стоит, но можете опубликовать на профильных сайтах информацию об уязвимости с целью предупредить клиентов системы о её ненадежности
Я не собирался их публиковать. Я думал переслать СБ организации, потому что в телефонном общении они не поняли, что ПД можно получать. Но факт наличия этих данных у меня, говорит о том, что я сам проникал в систему.
Анонимку отправьте.
если Вы проникали в систему без разрешения, это практически готовый состав преступления безотносительно к намерениям; надо так представить, что Вы узнали об уязвимости случайно, но не воспользовались ею без разрешения владельца данных.
да, и вряд ли стоит с ходу вымогать из конторы вознаграждение — это тоже можно на статью вывернуть
Ну есть же стандартный ход: «Смотрите, что я случайно нашел на Pastebin!»
Когда я во время heartbleed опубликовал на banki.ru список непропатченных банков, меня забанили.
Сейчас пытаюсь найти выход на МТС с их уязвимостью в личном кабинете. Телефонная поддержка тупит и не может никуда переключить, ибо просто некуда.
просите, чтобы с Вами связался представитель отдела экономической безопасности по поводу случайно найденной уязвимости в онлайн сервисе, которой Вы, конечно же, *не* воспользовались из опасений уголовного преследования
Что-бы попросить на меня выйти, надо знать кого просить. В этом то и проблема (с ростелекомом была ситуация аналогичная), когда выйти на компетентного человека невозможно.
Но благодаря хабру все решилось удачно. Представитель компании уже связался (приятно удивлен скоростью, да и фактом, что обратили внимание на простой комментарий) и процесс запущен.
Но благодаря хабру все решилось удачно. Представитель компании уже связался (приятно удивлен скоростью, да и фактом, что обратили внимание на простой комментарий) и процесс запущен.
ха, неужели сработал reputation management? мысли вслух, это система автоматического мониторинга информационного пространства… Или ребята просто хабр читают, что тоже вполне нормально;)
Вы попросили этого человека подтвердить, что он является сотрудником компании(например письмом с корпоративной почты)? А то может получиться, что слили уязвимость злоумышленнику.
Хорошее замечание, подумал об этом в первую очередь, но наша переписка началась по почте вида name@mts.ru, ip отправителя соответствовал диапазону «Mobile Telesystems OJSC», ну и по мелочи
Так куда в итоге писать? — если мне известно о явно некорректном(баг\фича?) поведении системы Альфа-Бизнес онлайн(Россия)?
Я писал письмо — через почту с банком — попросил передать текст в СБ, но мне ответили, что то типа «не, это ошибка не у нас и т.д.», хотя, любой программист заметил бы, что проблема явно присутствует и на стороне Альфа-Банка тоже — поскольку вообще позволяет создать ситуацию явно некорректного поведения совсем не хитрым образом. Это может быть как и банальная проблемка с декодированием юникода и до blind sql injection. Копать глубоко не стал, дабы не "догнали и еще раз не вознаградили". Если здесь есть компетентный представитель — пишите в личку сообщение с подтверждением принадлежности к компании.
Я писал письмо — через почту с банком — попросил передать текст в СБ, но мне ответили, что то типа «не, это ошибка не у нас и т.д.», хотя, любой программист заметил бы, что проблема явно присутствует и на стороне Альфа-Банка тоже — поскольку вообще позволяет создать ситуацию явно некорректного поведения совсем не хитрым образом. Это может быть как и банальная проблемка с декодированием юникода и до blind sql injection. Копать глубоко не стал, дабы не "догнали и еще раз не вознаградили". Если здесь есть компетентный представитель — пишите в личку сообщение с подтверждением принадлежности к компании.
На security@mts.ru не реагируют?
Ммм. Конкретно этот адрес не гуглится.
До почты не дошел, это был самый резервный план — сделать рассылку по живым людям + те, которые бы нашел на сайте (этот вариант сработал с ростелекомом).
В ходе диалога упоминался support@mts.ru, но после игры в пин-понг с сотрудниками полгода-год назад (делал заявку через feedback на сайте), когда ты ведешь диалог не с одним человеком из службы поддержки, а все время с новым (почему за тикетом не назначается один человек?!)… В общем это было то еще развлечение, пересказывать проблему по 10 раз по новой и случать типичные отписки
До почты не дошел, это был самый резервный план — сделать рассылку по живым людям + те, которые бы нашел на сайте (этот вариант сработал с ростелекомом).
В ходе диалога упоминался support@mts.ru, но после игры в пин-понг с сотрудниками полгода-год назад (делал заявку через feedback на сайте), когда ты ведешь диалог не с одним человеком из службы поддержки, а все время с новым (почему за тикетом не назначается один человек?!)… В общем это было то еще развлечение, пересказывать проблему по 10 раз по новой и случать типичные отписки
Это стандартный ящик, я когда рассылал информацию по сетевой дырке писал на него и на noc, с какого-нибудь обычно отвечали.
Стандарты это хорошо, главное чтобы их поддерживали, а я вот получил ответ на мой запрос через feedback сайта
WTF?! При том, что я написал про ошибку и приложил скриншот.
Благодарим Вас за обращение в Центр Клиентского сервиса МТС.
Александр, спасибо Вам за высказанные замечания. Хотим заверить Вас, что нами будут приложены максимальные усилия для того, чтобы Вы получали исключительно положительные эмоции от обслуживания в нашей компании. Надеемся на дальнейшее взаимовыгодное сотрудничество.
Спасибо Вам за интерес, проявленный к услугам нашей компании. Ваше мнение очень важно для нас.
WTF?! При том, что я написал про ошибку и приложил скриншот.
Схожую уязвимость нашел примерно год назад в ТКС — ответили очень быстро, исправили в течении 3х дней и зачислили 1500 бонусных миль.
dinikin несмотря на то, что мы (разработчики мобильного приложения) не можем напрямую влиять на политики Банка в части протоколов взаимодействия, хотел бы от имени Unreal Mojo поощрить вас небольшим сувениром. Если не сложно, пришлите ваш почтовый адрес на hello@unrealmojo.com.
Не понимаю такого. У кого-кого, а у банков должны быть деньги на хороших специалистов по безопасности, да они к тому же больше других в них заинтересованы. Откуда такая пугающая частота в банковских уязвимостях?
Просто их охотнее ищут. Да и больше боятся наказания за использование.
Похоже, это болезнь всех банков. Работал с человеком, которые прежде числился программистом в крупном банке. Большую часть времени он там занимался совещаниями и запросами на смену то или иной части. Само программирование занимало незначительную часть времени. Такая обстановка провоцирует частую смену кадров (значит никто не знает, что сделали до них). А те, которые остаются, в большинстве своем не торопятся исправлять баги (да и не способны), и предпочитают либо тихонько получать зарплату не привлекая внимания, либо проводить время у кофейника обрастая полезными связями в руководстве.
Я правильно понимаю, раз вы подменили сертификат на свой для https, в приложении нет валидации сертификата? SSL pining и вот это вот все…
получается, что нет, но разработчики пообещали посмотреть
Ясно-понятно. Просто таким простым маневром как НЕ отключение валидации сертификата (ну вот зачем? дебага ради?) или применением SSL pinning slavikus и КО сделали бы приложение гораздо более защищенным.
Вообще говоря, дешифрация это еще цветочки. Хуже всего, что отсутствие проверки валидности сертификата позволяет делать очень простые Man-In-The-Middle атаки: тупо называете wifi сеть Macdonalds_Free и тп и тд и перехватываете данные пользователя (логин, пароль), в момент оплаты можно подменить трафик с приложения и делать оплату своих услуг с подтверждением через SMS, а пользователю в ответ отдавать то, что он хочет видеть. Написать такой прокси — большого ума не нужно.
Обращаюсь ко всем разработчикам приложений: НЕ ОТКЛЮЧАЙТЕ ВАЛИДАЦИЮ SSL, если сертификат самоподписанный — используйте SSL pinning, пожалуйста!
По поводу SSL пининга есть гайд от OWASP: www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
Вообще говоря, дешифрация это еще цветочки. Хуже всего, что отсутствие проверки валидности сертификата позволяет делать очень простые Man-In-The-Middle атаки: тупо называете wifi сеть Macdonalds_Free и тп и тд и перехватываете данные пользователя (логин, пароль), в момент оплаты можно подменить трафик с приложения и делать оплату своих услуг с подтверждением через SMS, а пользователю в ответ отдавать то, что он хочет видеть. Написать такой прокси — большого ума не нужно.
Обращаюсь ко всем разработчикам приложений: НЕ ОТКЛЮЧАЙТЕ ВАЛИДАЦИЮ SSL, если сертификат самоподписанный — используйте SSL pinning, пожалуйста!
По поводу SSL пининга есть гайд от OWASP: www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
Это даст 100% защиту от сканирования и подмены трафика? Ведь получается в приложение прошивается некий ключ/сертификат который в теории можно достать путём декомпиляции?
Это будет открытый ключ, который вам ничего не даст.
Вшивается публичный ключ. Он и так известен.
SSL pinning защитит от MITM, т.к. не примет левый сертификат, и это очень важно, т.к. пользователи будут защищены.
Но траффик всегда можно расшифровать, например, можно собрать свою сборку Android с реализацией стандартного HTTP клиента или подменить тот HTTP клиент, который используется в приложении так, что оно будет вам весь траффик в лог писать, тут уже ничего не сделаешь.
Но траффик всегда можно расшифровать, например, можно собрать свою сборку Android с реализацией стандартного HTTP клиента или подменить тот HTTP клиент, который используется в приложении так, что оно будет вам весь траффик в лог писать, тут уже ничего не сделаешь.
Отключение валидации сертификата и Macdonalds не в тему. Сертификат проверяется используя корневые сертификаты из хранилища девайса. В статье указано, что расшифровка трафика стала возможна только после установки на девайс своего корневого сертификата.
Yan169 тут вы правы, а я нет. SSL pinning наше всё (правда у него тоже есть проблемы)
Какие?
Кстати, допустим, новый сертификат взамен старого выпускается за 1 неделю. За такой маленький срок не выпустить новое приложение. Как сделать правильно проверку в старой версии мобильного приложения до выпуска версии с новым сертификатом? Например, проверять все атрибуты, КРОМЕ срока действия.
Кстати, допустим, новый сертификат взамен старого выпускается за 1 неделю. За такой маленький срок не выпустить новое приложение. Как сделать правильно проверку в старой версии мобильного приложения до выпуска версии с новым сертификатом? Например, проверять все атрибуты, КРОМЕ срока действия.
Надо предусматривать такую ситуацию, это не сложно: если сертификат не сходится, нужно вывести пользователю диалог «Скорее всего, версия вашего приложения устарела, пожалуйста обновите приложение (либо у вас тут MITM)», ну и выпускать новую версию заранее, до протухания первого сертификата, чтобы большинство пользователей уже были обновлены.
В обновлении уже можно вшивать два публичных ключа: для старого сертификата и для нового, так вы сможете какое-то время поддержать старую версию сертификата, а затем безболезненно переключиться на новый.
А больше недостатков я не вижу, SSL pinning даже лучше, чем использование выданного «доверенным» центром сертификата, т.к. как мы уже слышали, их не сложно подменять на уровне государства, как уже делается в Китае
В обновлении уже можно вшивать два публичных ключа: для старого сертификата и для нового, так вы сможете какое-то время поддержать старую версию сертификата, а затем безболезненно переключиться на новый.
А больше недостатков я не вижу, SSL pinning даже лучше, чем использование выданного «доверенным» центром сертификата, т.к. как мы уже слышали, их не сложно подменять на уровне государства, как уже делается в Китае
С пиннингом есть вопрос отзыва сертификата в случае, если он по какой-то причине оказался скомпрометированным (напр. Heartbleed). Можно решить через пиннинг не конечного, а родительского сертификата, проверять дополнительно через дефолтную цепочку сертификатов, а отзывать через стандартную процедуру. Да, тогда доверяем своему центру сертификации, но это не то же самое, что доверять вообще всем сертификатам из хранилища девайса.
В этом был исходный вопрос: как сделать плавную миграцию на новый сертификат?
В нашей организации срок между окончанием действия старого сертификата и началом действия — 1 неделя. Понятно, что большинство клиентов не обновятся.
В нашей организации срок между окончанием действия старого сертификата и началом действия — 1 неделя. Понятно, что большинство клиентов не обновятся.
Какое преимущество даёт прикалывание сертификата, кроме усложнения обратного инжениринга? Если мы можем декомпильнуть программу или программа вообще опен-сорсная, то мы её сначала отучим от пининга и продолжим работу. Нет разве?
Конечно для себя вы с приложением можете сделать все что угодно, подменить сертификат, убрать проверки и прочее.
Но это никак не зааффектит пользователей, главная проблема для них — MITM: расшифровка данных, подмена ответов/запросов.
Это осуществимо либо при отсутствии проверок сертификата, либо, скажем, государствами, когда подвласный им корневой сертификат вшит в ОС и они могут подменить сертификат сервиса на подписанный ими и он, как правило, пройдет все проверки.
Но это никак не зааффектит пользователей, главная проблема для них — MITM: расшифровка данных, подмена ответов/запросов.
Это осуществимо либо при отсутствии проверок сертификата, либо, скажем, государствами, когда подвласный им корневой сертификат вшит в ОС и они могут подменить сертификат сервиса на подписанный ими и он, как правило, пройдет все проверки.
Ещё раз: о каком отсутствии проверок идёт речь? Сертификат проверяется на уровне ОС. Если вы говорите об SSL и о вшитых в ОС сертификатах, то они выпущены на конкретный домен Apple, а банковское ПО связывается с серверами банка.
Вот допустим, в iOS вшит сертификат для соединений с сервером обновлений Apple — как бы вы организовали MITM-аткаку любого рода?
Вот допустим, в iOS вшит сертификат для соединений с сервером обновлений Apple — как бы вы организовали MITM-аткаку любого рода?
Все довольно просто.
1) Сертификат проверяется не на уровне ОС, а на уровне процесса приложения, это может делать HTTP клиент из SDK или альтернативная реализация. Но это не суть.
2) Отсутствие проверок — вы можете отключить проверку сертификатов в HTTP клиенте, который используете. К сожалению, это довольно распространенная практика среди разработчиков, связано с тем, что часто тестовый сервер имеет самоподписанный сертификат и все такое прочее, что, естественно, не должно быть причиной.
3) Про вшитые в ОС сертификаты:
Есть два варианта генерации сертификата: вы можете получить сертификат у Доверенного центра сертификации или сгенерировать сертификат самостоятельно, например, через OpenSSL.
Суть Доверенных центров в том, их «корневые» сертификаты вшиты в ОС и эта информация обновляется в апдейтах вашей ОС.
В сертификате который вам пришел для https есть информация о том, каким доверенным центром он выдан. Когда HTTP клиент устанавливает https коннект, он по умолчанию попросит у ОС проверить, а правда ли данный сертификат выдан этим доверенным центром и все такое.
4) Так вот, как провести MITM:
Если сертификат выдан доверенным центром, то вариант только один — у проводящего атаку должен быть доступ к приватной части одного из вшитых в ОС корневых сертификатов, тогда можно сгенерировать свой сертификат и сделать так, чтобы MITM прокси отдавало свой сертификат клиентам вместо оригинального, и данный сертификат пройдет проверку, вот и все.
Проблема доверенных центров в том, что в вашей ОС установлено 200-300 корневых сертификатов доверенных центров, нередко, туда попадают сертификаты целых правительств, проверьте на своем девайсе, скорее всего, найдете сертификат правительства Китая, Японии, США и прочих стран/организаций.
Так вот, чтобы провести MITM на сертификат, выданный доверенным центром, вам достаточно быть в списке вшитых в ОС доверенных центров, далее уже ничего не спасет клиента.
А вот провести MITM на запинненный сертификат гоораздо сложнее, так как проверка подлинности не связана с доверенными центрами и выполняется чисто логикой приложения.
Надеюсь, я доступно объяснил. Могу, конечно, в чем то ошибаться, но в общих деталях всё должно быть верно, многое сам узнал из Security доклада на MobileCamp.
1) Сертификат проверяется не на уровне ОС, а на уровне процесса приложения, это может делать HTTP клиент из SDK или альтернативная реализация. Но это не суть.
2) Отсутствие проверок — вы можете отключить проверку сертификатов в HTTP клиенте, который используете. К сожалению, это довольно распространенная практика среди разработчиков, связано с тем, что часто тестовый сервер имеет самоподписанный сертификат и все такое прочее, что, естественно, не должно быть причиной.
3) Про вшитые в ОС сертификаты:
Есть два варианта генерации сертификата: вы можете получить сертификат у Доверенного центра сертификации или сгенерировать сертификат самостоятельно, например, через OpenSSL.
Суть Доверенных центров в том, их «корневые» сертификаты вшиты в ОС и эта информация обновляется в апдейтах вашей ОС.
В сертификате который вам пришел для https есть информация о том, каким доверенным центром он выдан. Когда HTTP клиент устанавливает https коннект, он по умолчанию попросит у ОС проверить, а правда ли данный сертификат выдан этим доверенным центром и все такое.
4) Так вот, как провести MITM:
Если сертификат выдан доверенным центром, то вариант только один — у проводящего атаку должен быть доступ к приватной части одного из вшитых в ОС корневых сертификатов, тогда можно сгенерировать свой сертификат и сделать так, чтобы MITM прокси отдавало свой сертификат клиентам вместо оригинального, и данный сертификат пройдет проверку, вот и все.
Проблема доверенных центров в том, что в вашей ОС установлено 200-300 корневых сертификатов доверенных центров, нередко, туда попадают сертификаты целых правительств, проверьте на своем девайсе, скорее всего, найдете сертификат правительства Китая, Японии, США и прочих стран/организаций.
Так вот, чтобы провести MITM на сертификат, выданный доверенным центром, вам достаточно быть в списке вшитых в ОС доверенных центров, далее уже ничего не спасет клиента.
А вот провести MITM на запинненный сертификат гоораздо сложнее, так как проверка подлинности не связана с доверенными центрами и выполняется чисто логикой приложения.
Надеюсь, я доступно объяснил. Могу, конечно, в чем то ошибаться, но в общих деталях всё должно быть верно, многое сам узнал из Security доклада на MobileCamp.
Ну нас интересую атаки на корректные реализации, а не случаи головотяпства программистов, поэтому пункты 1 и 2 пропустим — тут всё ясно.
К пункту 3): допустим, мобильный интернет-банк подключается к адресу mobile.alfabank.ru, а у меня на компьютере предустановлен корневой сертификат VeriSign. Для успешного подключения по SSL вам нужно выпустить сертификат для имени mobile.alfabank.ru, подписанный корневым сертификатом VeriSign. Никакой OpenSSL вам этого не сделает, поскольку вам для этого понадобится закрытая часть сертификата VeriSign. Если же вы обращаетесь в VeriSign официально, то, во-первых, он вам не выдаст сертификат на уже занятый (не вами) домен, во-вторых, обращаясь туда официально, вы деанонимизируете себя, чем упрощаете работу правоохранительным органам в случае мошенничества.
К пункту 4):
Вот именно, но где ж её взять?
В список доверенных центров ОС вы никак не попадёте (для этого вам нужно открыть доверенный центр, провести кучу переговоров и уж точно деанонимизировать себя), а если вы имели в виду — получить сертификат доверенного центра, то уже ответил выше — этот сертификат должен быть на конкретное доменное имя, иначе не прокатит.
Насколько я понял, ваша позиция сводится к вопросу доверия доверенным центрам. В общем-то разделяю опасения, но с теоретической стороны (если каждый субъект исправно выполняет свою роль) и без пининга всё должно работать вполне безопасно.
К пункту 3): допустим, мобильный интернет-банк подключается к адресу mobile.alfabank.ru, а у меня на компьютере предустановлен корневой сертификат VeriSign. Для успешного подключения по SSL вам нужно выпустить сертификат для имени mobile.alfabank.ru, подписанный корневым сертификатом VeriSign. Никакой OpenSSL вам этого не сделает, поскольку вам для этого понадобится закрытая часть сертификата VeriSign. Если же вы обращаетесь в VeriSign официально, то, во-первых, он вам не выдаст сертификат на уже занятый (не вами) домен, во-вторых, обращаясь туда официально, вы деанонимизируете себя, чем упрощаете работу правоохранительным органам в случае мошенничества.
К пункту 4):
у проводящего атаку должен быть доступ к приватной части одного из вшитых в ОС корневых сертификатов
Вот именно, но где ж её взять?
Так вот, чтобы провести MITM на сертификат, выданный доверенным центром, вам достаточно быть в списке вшитых в ОС доверенных центров, далее уже ничего не спасет клиента.
В список доверенных центров ОС вы никак не попадёте (для этого вам нужно открыть доверенный центр, провести кучу переговоров и уж точно деанонимизировать себя), а если вы имели в виду — получить сертификат доверенного центра, то уже ответил выше — этот сертификат должен быть на конкретное доменное имя, иначе не прокатит.
Насколько я понял, ваша позиция сводится к вопросу доверия доверенным центрам. В общем-то разделяю опасения, но с теоретической стороны (если каждый субъект исправно выполняет свою роль) и без пининга всё должно работать вполне безопасно.
Часто бюрократия ради бюрократии. По внутренним документам приложение остановить не так то просто. Заказ выполняла скорей всего сторонняя организация, в таком случаи могут параллельно запросить информацию у 3 компании чтоб она провела аудит уязвимости, потом это всё подписывается экспертами и только потом исправляется. После нужно подать документы на получение сертификатов, ведь там летают персональные данные.
Я с похожим сталкивался в обычной системе обработки заявок неисправностей, а тут целая банковская система.
Я с похожим сталкивался в обычной системе обработки заявок неисправностей, а тут целая банковская система.
Мне кажется, заголовок «по ЛЮБОМУ клиенту» неверен — ведь на самом деле по случайному клиенту.
Для Альфа-Банк Украина отключили возможность использования self-signed SSL certificates (для остальных стран она и так была выключена). Обновление уже доступно для скачивания в Google Play и находится на рассмотрении в App Store. Всем спасибо, мы продолжим усиливать меры безопасности в будущих обновлениях.
Берем запрос мобильного приложения, залогированный Fiddler и воспроизводим его в браузере Google Chrome при помощи плагина «Postman»
А зачем, если в Fiddler есть закладка Composer?
Sign up to leave a comment.
Уязвимость в одном из сервисов Альфа-Банка позволяла просматривать выписки по любому клиенту