Pull to refresh

Comments 61

Жесть. Позвонил им и задал вопрос в поддержке — будут ли они принимать меры или мне искать другой сервис. Сказали что у них все защищено, а любые статьи — происки конкурентов. То есть из серии -«Я закрыл глаза и меня теперь не видно».

Пошел искать новый сервис.
UFO just landed and posted this here
Никита,
мы ценим каждого клиента.
Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично. Мы очень благодарны Автору за данную статью, которая ускорила выполнения данной задачи.
Наши специалистами службы информационной безопасности компании еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации Автора описанные в статье частично выполнил. С момента обращения автора статьи и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено.

С уважением iPay.ua
Происки конкурентов
А вы действительно думали, что «call-center-girl» может вам дать квалифицированый ответ про XSS и прочее. У нее в программе такое не предусмотрено.

По теме же, проглядел мельком страничку — охватил тихий ужас: и это платежный сервис? Я просто промолчу, что у них даже заголовки типа X-Frame-Options, X-XSS-Protection и прочее не проставлены, про проверку referer, про «старый» софт с убунтой на сервере, про ...
Блин, проговорился таки.

Жую попкорн и жду развития событий, например угроз уважаемому dinikin, все дела… и наплыва черных ресерчеров.
UFO just landed and posted this here
Call-center-girl должна внимательно выслушать и записать всё, что ей скажут по поводу уязвимости и передать техдиру.

Да-да-да, а еще предложить вам на свидание пойти, вы же такой крутой кулхацкер…

Идеальные (call)центры вряд ли бывают, однако делать оценку «они нифига не предпринимают» (хотя возможно это на самом деле так) на основании ответа «глупой» девочки — как минимум не есть правильно.
Вот то, что они сообщение автора, судя по всему, всерьез не восприняли — это показатель. Как у них сайт сделан — тоже показатель. А девочка за телефоном, она на то и посажена, чтобы всех звонящих «успокоить».
Это во первых.

Во вторых, с чего вы взяли, что она не «выслушала», не «записала» и «не передала». Только потому, что она про это вслух не сказала?
К сожалению, квалифицированный саппорт попадается все реже. Причем, это касается не только нашего, но и западного рынка. Шаг в сторону и все — ноль на массу и никакой удобоваримой информации по проблеме.
Добрый вечер.

Алексей,
спасибо за Ваш звонок в поддержку, он был очень важен для нас и позволил очень оперативно закрыть таск по обращению автора статьм и статье автора в течение сегодняшнего дня. Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации автора частично выполнили. Спасибо сообществу и лично Вам за интерес к нашему сайту и безопасности наших клиентов. С момента обращения автора статьи и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено. С сотрудниками Контакт-Центра провели дополнительную работу. Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично. Будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.

С уважением iPay.ua
позволю себе привести пару цитат

>… в саппорт и мне ответили, что если разработчики посчитают нужным, свяжутся со мной. Но по истечении 3 недель (!!!) со мной ни кто так и не связался, а уязвимость так и остаётся открытой.

> Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут.

-----!

А так да, конечно, спасибо за звонок, ОН ОЧЕНЬ ВАЖЕН ДЛЯ НАС, бла-бла-бла
Уважаемый achempion,
Task по обращению Автора статьи (3 недельной давности) об уязвимости в саппорт был зарегистрирован, выставлен на IT разработчиков и поставлен в очередь на исполнение с момента обращения Автора статьи в сервис iPay.ua. Мы очень благодарны Автору за данную статью, которая ускорила выполнения данной задачи.
Наши специалистами службы информационной безопасности компании еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации Автора описанные в статье частично выполнил.

С уважением iPay.ua
Так, к слову: завязывали бы вы на Хабре шаблонами отвечать. Это вам не ваш support, здесь так не отвяжетесь от пользователя
Зелимхан,

мы не стремимся отвязаться от сообщества и не для этого отвечаем на вопросы, даём комментарии и устраняем описаные Автором в статье рекомендации.
То есть вас ничего не смущает в том, что критическая уязвимость — а возможность своровать данные карт, очевидно, является наиболее критической из возможных — закрывается три недели?

Ещё я бы с огромным интересом почитал, каким таким образом вы выяснили, что компроментаций карт не было. У вас все POST-запросы за три недели логируются?
Аналогично. Хотя, наверное, такой ответ и стоило ожидать…
Не вижу поля для комментария на странице, убрали уже?
Поставьте курсор в поле «Телефон получателя»
Автор топика отправлят те же данные что прислал сам. Логично было бы обренуть отправку в конструкцию типа:
$( 'input1, input2,...' ).change(function() {
Похоже, что уже исправили.
Публичная огласка крайне эффективна.
Да, частично закрыли, но XSS на странице пока присутствует.
Да, пару костылей вставили: отключили вставку в поле из буфера обмена, и стирают некоторые символы (вроде < и /) на keyup.
Что делать, если у меня номер телефона «DROP DATABASE...»?
Увы, проблема финансовых компаний и банков в том, что они истинно веруют в аудиторскую часть 27001/PSI-DSS/Cobit, забивая на практическую часть этих же стандартов и рекомендаций, особенно в плане периодических пентестов.
В итоге в каждой «солидной» финансовой организации обязательно сидит свой безопасник, а то и два, жмякает раз в неделю на акунетикс, сканируя тот список узлов, который сам впишет, и создает красивый отчет для имитации бурной деятельности.
То, что эта деятельность далека от практической безопасности, понимают единицы в такой «солидной» финансовой организации, но их либо не слушают, либо они не хотят нести ответственность за новые расходы, которые нужно ещё обосновать и выбить.
В итоге имеем ту самую бумажную «безопасность», обвешанную сертификатами и бумажками, а с практикой фейл.
Так периодические пентесты (не менее раз в год) по PCI DSS надо делать в качестве обязаловки только с 30.06.2015, читайте — с 1-го июля. А до этого — рекомендация, и для прохождения на соответствие предоставление результатов пентеста не нужно, хватает ежеквартального ASV. Раз не обязательно — никто и не почешется, не такое уж и дешевое удовольствие (и самое главное, в некоторых случаях — не такое уж безболезненное удовольствие :) ) заказывать пентест у сторонней организации при отсутствии в штате «своих» пентестеров.
Добрый вечер.
Уважаемый Автор (dinikin) и сообщество, в первую очередь от лица компании iPay.ua хотим поблагодарить Вас за проявленный интерес к сервису «денежных переводов с карты на карту» и его непосредственное тестирование на уязвимость.
Task по Вашему обращению об уязвимости в саппорт был зарегистрирован, выставлен на IT разработчиков и поставлен в очередь на исполнение с момента обращения в сервис iPay.ua. Мы очень благодарны Вам за данную статью, которая ускорила выполнения задачи.
Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но Ваши рекомендации частично выполнили. Спасибо сообществу за интерес к нашему сайту и безопасности наших клиентов.
С момента Вашего обращения и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено.
Будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.
Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично.

Наш официальный комментарий к статье размещён www.ipay.ua/ru/news/podtverjdenie-bezopasnosti-servisa-ipay-ua
С уважением сотрудники iPay.ua
Уважаемый mao1985! По моему мнению, ваш ответ наполнен вежливым текстом, но лишен здравого смысла.

dinikin очень детально и наглядно продемонстрировал использование уязвимости, но мне не понятно что вы имели ввиду под
Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили

Типичный ответ от такого сервиса. Я лично удивился бы, если что-то другое увидел.

Сейчас же компаниям главное показать типичным пользователям, что всё в порядке, можно и дальше их сервисом пользоваться, нежели признать наличие уязвимости и то, что их пользователи всё это время были под угрозой
Зелимхан,

мы умеем не только признавать ошибки, но и прислушиваться к рекомендациям и выполнять их.

С момента обращения Автора и публикации статьи — фактов компрометации карт на сайте iPay.ua не было.

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

Потенциальная угроза очевидна — слив номера карты, срока действия, cvv кода.

Вы говорите, что:
методов их эксплуатации не выявили

Как по мне, метод — это последовательность шагов, которые нужно выполнить, чтобы добиться результата. Результат — угон данных карточки. Шаги со скринами в статье. Вы хотите сказать, что поле комментарий не было подвержено уязвимости XSS?
SilverFire, XSS не является уязвимостью, об этом уже было проговорено на хабре — habrahabr.ru/post/149152
В данной же статье описана возможность сбора карт при подмене ресурса фишинговым сайтом. А в таком случае это уже уголовная статья, и мы постоянно проводим мониторинг откуда идёт трафик и мы не раздаём ссылки на данный сервис на право и на лево. Поэтому после оценки угрозы, задача была поставлена в очередь на выполнение.
Вы вероятно невнимательно читали статью. Подмены ресурса не происходит, зловредный код выполняется на вашем сайте.
dinikin, мы очень внимательно читали Вашу статью, раза по 2 минимум, поставил бы смайл — да запрещено Хабром. Все сотрудники компании iPay.ua перечитали, а некоторые перечитывали её по 3-4 раза в профилактических целях.

Чтобы запустить зловредный код встроенный нам в сервис — клиент/пользователь должен был попасть с страницы злоумышленника (сторонний сайт) это тоже уголовка и мы мониторим заходы на сайт постоянно (трафик, подозрительный трафик), и блочим ресурсы, страницы… Или Ваш код запускался не при переходе на страницу p2p с сторонней страницы (специального фишингового банера)?

Ваши некоторые рекомендации сегодня были выполнены, за них отдельное огромная благодарность. И насколько меня заверили наши программисты и безопасники — сейчас всё ещё более безопасно, чем было. Мы будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.
Простите, а вы когда-нибудь в жизни имели дело с расследованиями кибератак и розыском взломщиков-злоумышленников? Вы представляете себе, какова вероятность найти преступника в данном случае, будь то «уголовка» или что угодно?
Присоединяюсь к вопросу. Вы будете знать HTTP referer, где была размещена ссылка (какой-то форум) и IP жертвы.
Кого вы сможете привлечь к ответственности? Пользователя форума, который опубликовал ссылку, сидя за китайской прокси?

ИМХО, жертве реальнее привлечь вас к ответственности, так как данные были слиты в следствие выполнения вредоносного кода на вашем сайте.
Извините, если я нахожусь вне Украины — то как вы по отношению ко мне примените эту уголовку?
И почему, если я попадаю со стороннего сайта на вашу платежную систему (например, с интернет-магазина, где выбрал в качестве способа оплаты вашу платежную систему, после чего меня на нее перекидывает, а в поле «комментарий» автоматом подставляется какой-то код, позволяющий мне, как владельцу магазина, идентифицировать ваш платеж и отправить вам товар) — это уголовка?
Да я еще на сайте крупно пропишу, что-то вроде «Уважаемый покупатель! Для однозначной идентификации вашего платежа не стирайте код вашей покупки в поле комментария платежной системы! Также, в этом поле вы должны указать (<что-то важное, чтобы пользователь точно вписал>)». Готово — большая часть пользователей выполнит инструкцию. А вот то, что выполнится зловредный код на вашем сайте — это уже ваши проблемы… И это, безусловно, уязвимость.
Ваши безопасники, ради интереса, пробовали CVSS по этой проблеме подсчитать? Базовую оценку.
А с помощью чего вы отслеживаете источники входа?

Судя по происходящему, есть мало-мальски настроенный Google Analytics, в котором, вероятно, вы и мониторите входы.
Что будет если я банально пропишу utm-метки в источнике трафика и канале?

image

Заменив fake_google на google в статистике будет невозможно отличить любой реферральный переход от органического с google.
mao1985, действительно, тут можно маневрировать с термином «уязвимость». Нужно еще чуток заморочиться, чтобы загнать жертву на страницу оплаты, где она доведет транзакцию до конца, но как proof-of-concept — очень даже хорошо.

при подмене ресурса фишинговым сайтом

Ведь речь идет не о подмене iPay фишинговым сайтом. Достаточно отправить к вам пользователя с определенными данными.
Пфф. просто провередите эксперемент, дайте ему ссылку по которой кидает дальше на сайт оплаты. Пусть он введет данные своей карточки и потом узнаем получилось ли увести данные или нет. Если он так уверен, что все безопасно.
Жесть, а я же платил через ваш сервис. А ваше отношение к безопасности меня отпугнуло. Если вам описали такую дыру и вы за три недели даже не удосужились ее закрыть, что будет с теми дырами в которые вам не ткнут носом и не напишут на сайте?
Замечательно у них поставлен PR в компании. По тем же принципам бумажных стандартов и без включения мозга? Я к тому, что количество копипасты в комментариях от товарища mao1985 зашкаливает за любые разумные пределы.
Кстати, а вообще какие есть доказательства что он сотрудник iPay.ua? Может быть он тупо троллит?
Тогда это тролль 80-го лвла, раз так спокойно себе карму сливает
Кто-нибудь понимает, в чём смысл вот этих слов: «С момента Вашего обращения и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено»? Имеется в виду момент длиной в три недели?
А зачем вообще в этом поле комментария вешать обработчик на каждое нажатие кнопки? О_о
В нашей реальности можно радоваться, что не «догнали и еще раз не вознаградили»… =( Не так давно была статья, что за аналогичное сообщение в банк автора выставили, как злоумышленника, вместо спасибо. Так что не удивлюсь.
В нашей реальности можно радоваться, что не «догнали и еще раз не вознаградили»… =( Не так давно была статья, что за аналогичное сообщение в банк автора выставили, как злоумышленника, вместо спасибо. Так что не удивлюсь.
Прошу прощения за дублирование поста,
Да, не переживай. Второй раз даже лучше получилось.
В данный момент сайт не работает и висит сообщение «Уважаемый Клиент, сайт iPay.ua временно недоступен. Приносим извинения за временные неудобства, в ближайшее время сайт возобновит свою работу.»
Так что может все же решили исправить проблемы найденные автором…
Либо решили прикрыть на время хайпа, чтобы не нашли дырку получше
Вероятно информация дошла до компетентного соотрудника или начальства.
А как вы обойдете sameOrigin полиси для отправки данных на сторону? Через CORS?
Same-origin policy для XMLHttpRequest ограничивает только чтение ответа от стороннего домена, отправку данных она не ограничивает.
То есть как не ограничивает? Если из браузера идёт XHR на домен, то сначала сам браузер делает запрос OPTIONS и смотрит на CORS-заголовки, и если сервер не разрешает, то XHR зафейлится сразу, никакого запросы отправлено не будет.
да, верно, тогда либо выставлять на домене CORS-заголовки, либо слать данные GET запросом
Sign up to leave a comment.

Articles

Change theme settings