Chonokai
Резидент
- Статус
- offline
- Регистрация
- 13.11.2020
- Сообщения
- 70
- Репутация
- 260
Подозрительная личность! Работать только через гарант-сервис!
Данная тема достаточно сухая, куча информации для "технарей", но я постарался придерживаться публицистики, не скатываться в нудятину и разбавлять статью интересными (насколько это возможно в данной сфере) случаями. Приятного чтения
Речь будет идти не о сливах больших количеств данных, не о базах которые выкладываются, не о общедоступных эксель документах с зараженными Covid’ом, а о классических уязвимостях information disclosure.
По каталогу CWE (Common Weakness Enumeration) этот тип уязвимости занимает 7 место из 25 в топе за 2020 год и по сути это одна из самых распространенных типов уязвимостей, но при этом, одна из самых недооцененных. Во первых потому что, большую часть таких уязвимостей представляют какие то простые случаи с утечкой debug информации в логах, с малозначительным раскрытием информации, которая не поможет хакеру залезть в систему, но, при этом, всегда остается возможность раскрытия очень чувствительной информации. Например, как в случае с раскрытием администратора группы фейсбука в исходном коде страницы. Скрин ниже:
https://seekurity.com/blog/2018/02/...acebook-pages-admins-disclosure-vulnerability
Это кейс, в котором за 2.5 минуты ресерчер получил 2.5к долларов, просто за то, что открыл исходный код письма и нашел там в приглашении вступить в группу чувствительные данные, которые по сути, должны быть скрыты ото всех. И если такой кейс вас не удивит, то вот например другой случай с нахождением личных паспортных данных бывшего премьер – министра Австралии просто в исходном коде страницы сайта авиаперевозчика.
https://mango.pdf.zone/finding-form...ter-tony-abbotts-passport-number-on-instagram
Это причина, по которой нельзя публиковать в социальных сетях свои билеты, потому что на каждом авиабилете перевозчик печатает номер пассажира, по международной классификации и по этому номеру пассажира можно совершенно без какого то пароля зайти на сайт авиаперевозчика и там посмотреть какие то личные данные по полетам. И в том числе, какие то перевозчики прямо в исходном коде страниц сохраняют все доступные данные из базы.
В чем роль утечек в OSINT именно в текущем комьюнити с нынешним статусом?
В качестве примера прикрепил скриншот переписки с HR одной из известных российских компаний. Который в качестве описания того, чем они занимаются, написал (скрин ниже)
Собственно, это позиционирование, которое сквозит много откуда, и не только в российском комьюнити, потому что утечки персональных данных – это по сути золотая жила. Полулегальная, неофициальная, но позволяющая добывать много информации о людях и монетизировать это.
Где утекают персональные данные? Не такой сложный вопрос. На самом деле, практически все сервисы, которые имеют у себя базу данных с личными профилями и имеют какую то функциональность по регистрации, авторизации, восстановлении пароля – в этих же местах и допускают утечки. Вместе с тем и просто в исходных кодах страниц бывают скрыты данные, которые изначально полагаются приватными и никому не раскрываются. Плюс, часто есть такая функциональность как инвайты, как в случае с фейсбук, как предоставление каких то полномочий, разрешений и вообще допускающие любые пользовательские взаимодействия. Везде в этих местах мы можем найти, при пристальном взгляде, утечку каких либо персональных данных.
Простой пример:
Это на самом деле не утечка, потому что здесь нет приватной информации, вся она публична, но интересный кейс для старта
Если вы попробуете зарегистрироваться на сайте VT, то, достаточно вводить юзернейм в соответствующем поле, как на сервер начнут отправляться запросы с этим юзернеймом для проверки зарегистрирован он или нет. Казалось бы, что должен вернуть этот запрос к серверу, он наверное должен вернуть значения “да/нет”, на самом деле он возвращает массив всех доступных данных о пользователе с таким никнеймом. Если он есть, то, вот пожалуйста вам портянка с именем, с никнеймом, с датой регистрации со статусом и т.д. Если его нет – то извините, ничего. Такие кейсы встречаются достаточно часто и иногда в таких данных прилетают совершенно неожиданные штуки.
Перейдем к частичному раскрытию данных. Начнем как раз с регистрации и авторизации. Возможно вы узнаете сервисы, которые приведены на этих скринах
Это достаточно простая форма восстановления пароля, которая тем не менее, предлагает вам убедится, что вы отправляете какой то код для восстановления на тот ящик или тот телефон, который принадлежит вам. Фейсбук, например, раскрывает почти все реквизиты, что у вас есть, закрывая всё это звездочками. По теме звездочек есть отдельные работы, о том, как можно эти звездочки вскрывать, даже восстанавливать номер полностью, используя восстановления пароля на разных сервисах. Об этом будет чуть позднее. Суть в том, что практически любой сервис авторизации имеет такую функциональность и позволяет вам, зная адрес аккаунта узнать его и примерный почтовый ящик и номер телефона.
Ниже реальный пример одного из провайдеров связи:
На верхнем скрине видим, что если человек знает номер договора/телефона/почту, то он может восстановить доступ ко всему остальному. Поэтому если вам известно что либо из списка, вы это вбиваете, продвигаетесь дальше и вам предлагается строка с закрытыми звездочками остальными реквизитами, но при этом, в ajax запросе к серверу, в ответ на него прилетает полная портянка с номером договора без звездочек, с почтой, которая тоже немного закрыта звездочками. Не трудно догадаться что это домен mail.ru, а зная фамилию человека на которого зарегистрирован этот договор, можно и предположить какой мейл был до @.
Что вы можете получить, зная и используя всю эту функциональность?
Вы можете получить кусочки персональных данных по любому идентификатору, который считается первичным в системе. Это либо какой то id в случае фейсбука, юзернейм, который уникален в пределах сервиса. Номер телефона и почта. То есть фактически любые данные которые у вас есть на человека, могут стать входной точкой, для того что бы восстановить по крупицам все остальные.
Естественно, если использовать в связке множество сервисов, то вы получаете возможность собрать все что привязано к человеку. По сути все это сводится к массовой эксплуатации механизма восстановления логина – пароля. Удостоверившись в работоспособности данной схемы, люди создают различные утилиты, для абуза, примеры ниже:
https://github.com/martinvigo/email2phonenumber
https://github.com/megadose/holehe
Все они пользуются функциональностью регистрационной формы и пытаются из этого вычленить нужную вам информацию.
Важная вещь, которую стоит упомянуть. Двухфакторная и вообще мультифакторная аутентификация, про которую часто говорят, как про одну из обязательных мер защиты от взлома, она при этом может быть проблемой приватности. Потому что привязывая вторичные имейлы, номера телефонов для восстановления, вы даете возможность сервису эти реквизиты показать еще кому то.
Перейдем к полному раскрытию данных.
В качестве примера я приведу случай с раскрытием электронного ящика Google по запасному ящику. Думаю все, кто пользовались аккаунтом гугл, получали время от времени уведомление из серии “не хотите ли проверить свою безопасность, приватности. Привяжите резервный ящик/номер телефона, на случай восстановления.” Неудивительно, я думаю, что у гугла в большом количестве его сервисов кое где протекает функциональность, которая позволяет связать эти два номера.
В данном кейсе происходит получение прав доступа к Google Analytics. Здесь нет интерфейса, только сообщение, поэтому расскажу на словах.
Всё просто – вы хотите предоставить доступ кому то к аналитике сайта и вбиваете его мейл. Если этот имейл, скажем с доменом mail.ru, если он является запасным ящиком какого то сервиса на gmail, то появляется подсказка, мол, мы знаем что этот ящик является альтернативным по отношению к такому. Это казалось бы какое то раскрытие приватной информации, но при этом до сих пор это не пофикшено и официально тому человеку, кто это нашел, ответили что “это не баг, а фича. Так надо”. Интересная вещь, что вместе с первичным электронным ящиком, здесь еще раскрывается уникальный идентификатор пользователя с названием GAIA ID. О котором мы еще поговорим.
Что мы можем делать с подобными утечками?
Вы можете получить реальный аккаунт, человека, который анонимен. Это достаточно частый кейс, когда люди используют несколько почт и одна из них привязана к их реальной личности, иногда содержит в логине или пароле их персональные данные. Так же нередким случаем является когда подобного рода ситуация происходит и с резервной почтой. Так или иначе, этот клубок можно распутать в обе стороны. Так же легко, как и по итогу подтвердить связь обоих ящиков. Так же, можно использовать этот уникальный ID, что бы узнать информацию из других сервисов. Есть инструменты, которые это используют:
https://tools.epieos.com/google-account.php
Давайте посмотрим, для сравнения, еще одну уязвимость, которая тоже позволяет раскрывать почту, но, при этом, действительно была засчитана уязвимостью со стороны Google и человек нашедший ее получил вознаграждение. Она была немного сложнее и хитрее и позволяла опять же при знании идентификатора пользователя получить основной имейл. Заключалась она в следующем.
Многие, наверное заходили в настройки дашборда гугла и возможно видели, что в ссылке находится тот самый цифровой идентификатор
Многие люди с разумом хацкера подумают, а что получится если этот идентификатор сменить? Так подумал один из исследователей, ссылка на работу которого ниже
И попробовал заменить его на идентификатор совершенно случайного пользователя. Его перекинуло на страницу логина с приглашением добавить новый электронный ящик к его существующей учетной записи и поле ввода уже было заботливо заполнено основным электронным ящиком того человека, которому был сопоставлен этот ID.
Возникает вопрос, что еще можно делать с такими айдишниками, если они позволяют по сути выяснять всю связку данных пользователя.
Касательно самого гугла и его экосистемы.
На этом скриншоте приведена только часть всех сервисов, которым владеет гугл. И наверняка в какую то часть этих сервисов вы так или иначе заходили, пускай и случайно. И вместе с тем, у гугла есть только один аккаунт, который позволяет заходить в эти сервисы, что вполне справедливо и удобно. Вам не нужно регистрироваться везде, достаточно просто иметь ящик gmail. Вместе с тем возникают закономерные риски, которые при компрометации учетной записи на каком то одном сервисе, позволяют узнать информацию на всех остальных.
Так перейдем же к использованию того самого идентификатора гугла, что можно из него выжать:
- Имя пользователя
- Время последнего изменения профиля
- Сервисы, которыми юзер пользовался
- Ютуб каналы, которые возможно связаны с этим айдишником
- Юзернеймы
- Публичные фотографии
- Модель телефона, прошивки, установленное ПО
- Обзоры на картах гугл, физическое расположение юзера
- События из гугл календаря
Стоит сделать оговорку, при максимальном уровне приватности пользователя, часть этих данных разумеется будет недоступна. Но давайте будем реалистами, большинство не лезет в настройки гугл и такое же большинство даже не подозревает что у них на том или ином устройстве какая то часть этих гугл сервисов вообще функционирует.
Как эту информацию получить быстро и без навыков супер хакера осинтера?
Есть относительно новая утилита под названием GHunt
https://github.com/mxrch/GHunt
Вам достаточно иметь только ящик почты, который привязан в гуглу, он может быть на любом домене и по нему утилита найдет всю доступную информацию, которая есть в гугле.
Естественно гугл это не единственный пример экосистемы сервисов, которые раскрывают о пользователе всё, что можно, а так же не единственный пример экосистемы в которой на один аккаунт завязаны все остальные сервисы.
Яндекс берет пример, но при этом все таки старается обезопасить пользователя. На схеме ниже представлена связка сервисов яндекса
Не во всех этих сервисах можно по никнейму пользователя и почте получить его профиль, но вместе с тем, они используют некий набор идентификаторов, допустим логин или внутренний айдишник и PublicID. И по этим идентификаторам так или иначе можно из одного сервиса выйти на другой.
Как пример, ребята из HowToFind в ходе исследования зарепортили уязвимость в Яндекс Дзен. Они нашли просто в исходном коде PublicID создателя статей на Дзене.
Не останавливаясь на яндексе, давайте подумаем о том, что с нами всегда – это наши телефоны. У всего этого тоже присутствуют экосистемы сервисов и чаще всего прямо скажем они не самого высокого качества. В ходе исследований были найдены ряд интересных вещей, таких как например восстановления доступа у одного из производителей, который раскрывает все электронные ящики и номера телефонов. Плюс модели устройств, в которые вы входили и точки доступа wifi, к которым вы хотя бы раз подключались. По точкам вайфая можно определить примерный ареал обитания юзера, просто пользуясь картами.
Второй производитель позволяет получить уникальные идентификаторы, так еще и на других сервисах позволяет запрашивать огромными массивами информацию о пользователе просто зная UserID.
Речь будет идти не о сливах больших количеств данных, не о базах которые выкладываются, не о общедоступных эксель документах с зараженными Covid’ом, а о классических уязвимостях information disclosure.
По каталогу CWE (Common Weakness Enumeration) этот тип уязвимости занимает 7 место из 25 в топе за 2020 год и по сути это одна из самых распространенных типов уязвимостей, но при этом, одна из самых недооцененных. Во первых потому что, большую часть таких уязвимостей представляют какие то простые случаи с утечкой debug информации в логах, с малозначительным раскрытием информации, которая не поможет хакеру залезть в систему, но, при этом, всегда остается возможность раскрытия очень чувствительной информации. Например, как в случае с раскрытием администратора группы фейсбука в исходном коде страницы. Скрин ниже:
https://seekurity.com/blog/2018/02/...acebook-pages-admins-disclosure-vulnerability
Это кейс, в котором за 2.5 минуты ресерчер получил 2.5к долларов, просто за то, что открыл исходный код письма и нашел там в приглашении вступить в группу чувствительные данные, которые по сути, должны быть скрыты ото всех. И если такой кейс вас не удивит, то вот например другой случай с нахождением личных паспортных данных бывшего премьер – министра Австралии просто в исходном коде страницы сайта авиаперевозчика.
https://mango.pdf.zone/finding-form...ter-tony-abbotts-passport-number-on-instagram
Это причина, по которой нельзя публиковать в социальных сетях свои билеты, потому что на каждом авиабилете перевозчик печатает номер пассажира, по международной классификации и по этому номеру пассажира можно совершенно без какого то пароля зайти на сайт авиаперевозчика и там посмотреть какие то личные данные по полетам. И в том числе, какие то перевозчики прямо в исходном коде страниц сохраняют все доступные данные из базы.
В чем роль утечек в OSINT именно в текущем комьюнити с нынешним статусом?
В качестве примера прикрепил скриншот переписки с HR одной из известных российских компаний. Который в качестве описания того, чем они занимаются, написал (скрин ниже)
Где утекают персональные данные? Не такой сложный вопрос. На самом деле, практически все сервисы, которые имеют у себя базу данных с личными профилями и имеют какую то функциональность по регистрации, авторизации, восстановлении пароля – в этих же местах и допускают утечки. Вместе с тем и просто в исходных кодах страниц бывают скрыты данные, которые изначально полагаются приватными и никому не раскрываются. Плюс, часто есть такая функциональность как инвайты, как в случае с фейсбук, как предоставление каких то полномочий, разрешений и вообще допускающие любые пользовательские взаимодействия. Везде в этих местах мы можем найти, при пристальном взгляде, утечку каких либо персональных данных.
Простой пример:
Это на самом деле не утечка, потому что здесь нет приватной информации, вся она публична, но интересный кейс для старта
Если вы попробуете зарегистрироваться на сайте VT, то, достаточно вводить юзернейм в соответствующем поле, как на сервер начнут отправляться запросы с этим юзернеймом для проверки зарегистрирован он или нет. Казалось бы, что должен вернуть этот запрос к серверу, он наверное должен вернуть значения “да/нет”, на самом деле он возвращает массив всех доступных данных о пользователе с таким никнеймом. Если он есть, то, вот пожалуйста вам портянка с именем, с никнеймом, с датой регистрации со статусом и т.д. Если его нет – то извините, ничего. Такие кейсы встречаются достаточно часто и иногда в таких данных прилетают совершенно неожиданные штуки.
Перейдем к частичному раскрытию данных. Начнем как раз с регистрации и авторизации. Возможно вы узнаете сервисы, которые приведены на этих скринах
Это достаточно простая форма восстановления пароля, которая тем не менее, предлагает вам убедится, что вы отправляете какой то код для восстановления на тот ящик или тот телефон, который принадлежит вам. Фейсбук, например, раскрывает почти все реквизиты, что у вас есть, закрывая всё это звездочками. По теме звездочек есть отдельные работы, о том, как можно эти звездочки вскрывать, даже восстанавливать номер полностью, используя восстановления пароля на разных сервисах. Об этом будет чуть позднее. Суть в том, что практически любой сервис авторизации имеет такую функциональность и позволяет вам, зная адрес аккаунта узнать его и примерный почтовый ящик и номер телефона.
Ниже реальный пример одного из провайдеров связи:
На верхнем скрине видим, что если человек знает номер договора/телефона/почту, то он может восстановить доступ ко всему остальному. Поэтому если вам известно что либо из списка, вы это вбиваете, продвигаетесь дальше и вам предлагается строка с закрытыми звездочками остальными реквизитами, но при этом, в ajax запросе к серверу, в ответ на него прилетает полная портянка с номером договора без звездочек, с почтой, которая тоже немного закрыта звездочками. Не трудно догадаться что это домен mail.ru, а зная фамилию человека на которого зарегистрирован этот договор, можно и предположить какой мейл был до @.
Что вы можете получить, зная и используя всю эту функциональность?
Вы можете получить кусочки персональных данных по любому идентификатору, который считается первичным в системе. Это либо какой то id в случае фейсбука, юзернейм, который уникален в пределах сервиса. Номер телефона и почта. То есть фактически любые данные которые у вас есть на человека, могут стать входной точкой, для того что бы восстановить по крупицам все остальные.
Естественно, если использовать в связке множество сервисов, то вы получаете возможность собрать все что привязано к человеку. По сути все это сводится к массовой эксплуатации механизма восстановления логина – пароля. Удостоверившись в работоспособности данной схемы, люди создают различные утилиты, для абуза, примеры ниже:
https://github.com/martinvigo/email2phonenumber
https://github.com/megadose/holehe
Все они пользуются функциональностью регистрационной формы и пытаются из этого вычленить нужную вам информацию.
Важная вещь, которую стоит упомянуть. Двухфакторная и вообще мультифакторная аутентификация, про которую часто говорят, как про одну из обязательных мер защиты от взлома, она при этом может быть проблемой приватности. Потому что привязывая вторичные имейлы, номера телефонов для восстановления, вы даете возможность сервису эти реквизиты показать еще кому то.
Перейдем к полному раскрытию данных.
В качестве примера я приведу случай с раскрытием электронного ящика Google по запасному ящику. Думаю все, кто пользовались аккаунтом гугл, получали время от времени уведомление из серии “не хотите ли проверить свою безопасность, приватности. Привяжите резервный ящик/номер телефона, на случай восстановления.” Неудивительно, я думаю, что у гугла в большом количестве его сервисов кое где протекает функциональность, которая позволяет связать эти два номера.
В данном кейсе происходит получение прав доступа к Google Analytics. Здесь нет интерфейса, только сообщение, поэтому расскажу на словах.
Всё просто – вы хотите предоставить доступ кому то к аналитике сайта и вбиваете его мейл. Если этот имейл, скажем с доменом mail.ru, если он является запасным ящиком какого то сервиса на gmail, то появляется подсказка, мол, мы знаем что этот ящик является альтернативным по отношению к такому. Это казалось бы какое то раскрытие приватной информации, но при этом до сих пор это не пофикшено и официально тому человеку, кто это нашел, ответили что “это не баг, а фича. Так надо”. Интересная вещь, что вместе с первичным электронным ящиком, здесь еще раскрывается уникальный идентификатор пользователя с названием GAIA ID. О котором мы еще поговорим.
Что мы можем делать с подобными утечками?
Вы можете получить реальный аккаунт, человека, который анонимен. Это достаточно частый кейс, когда люди используют несколько почт и одна из них привязана к их реальной личности, иногда содержит в логине или пароле их персональные данные. Так же нередким случаем является когда подобного рода ситуация происходит и с резервной почтой. Так или иначе, этот клубок можно распутать в обе стороны. Так же легко, как и по итогу подтвердить связь обоих ящиков. Так же, можно использовать этот уникальный ID, что бы узнать информацию из других сервисов. Есть инструменты, которые это используют:
https://tools.epieos.com/google-account.php
Давайте посмотрим, для сравнения, еще одну уязвимость, которая тоже позволяет раскрывать почту, но, при этом, действительно была засчитана уязвимостью со стороны Google и человек нашедший ее получил вознаграждение. Она была немного сложнее и хитрее и позволяла опять же при знании идентификатора пользователя получить основной имейл. Заключалась она в следующем.
Многие, наверное заходили в настройки дашборда гугла и возможно видели, что в ссылке находится тот самый цифровой идентификатор
Многие люди с разумом хацкера подумают, а что получится если этот идентификатор сменить? Так подумал один из исследователей, ссылка на работу которого ниже
Google Exploit - Steal Account Login Email Addresses - Tom Anthony
I found a bug that allowed me to find anyone with a Google+ account's login email address. This could be used to target specific people for spear phishing.
www.tomanthony.co.uk
И попробовал заменить его на идентификатор совершенно случайного пользователя. Его перекинуло на страницу логина с приглашением добавить новый электронный ящик к его существующей учетной записи и поле ввода уже было заботливо заполнено основным электронным ящиком того человека, которому был сопоставлен этот ID.
Возникает вопрос, что еще можно делать с такими айдишниками, если они позволяют по сути выяснять всю связку данных пользователя.
Касательно самого гугла и его экосистемы.
На этом скриншоте приведена только часть всех сервисов, которым владеет гугл. И наверняка в какую то часть этих сервисов вы так или иначе заходили, пускай и случайно. И вместе с тем, у гугла есть только один аккаунт, который позволяет заходить в эти сервисы, что вполне справедливо и удобно. Вам не нужно регистрироваться везде, достаточно просто иметь ящик gmail. Вместе с тем возникают закономерные риски, которые при компрометации учетной записи на каком то одном сервисе, позволяют узнать информацию на всех остальных.
Так перейдем же к использованию того самого идентификатора гугла, что можно из него выжать:
- Имя пользователя
- Время последнего изменения профиля
- Сервисы, которыми юзер пользовался
- Ютуб каналы, которые возможно связаны с этим айдишником
- Юзернеймы
- Публичные фотографии
- Модель телефона, прошивки, установленное ПО
- Обзоры на картах гугл, физическое расположение юзера
- События из гугл календаря
Стоит сделать оговорку, при максимальном уровне приватности пользователя, часть этих данных разумеется будет недоступна. Но давайте будем реалистами, большинство не лезет в настройки гугл и такое же большинство даже не подозревает что у них на том или ином устройстве какая то часть этих гугл сервисов вообще функционирует.
Как эту информацию получить быстро и без навыков супер хакера осинтера?
Есть относительно новая утилита под названием GHunt
https://github.com/mxrch/GHunt
Вам достаточно иметь только ящик почты, который привязан в гуглу, он может быть на любом домене и по нему утилита найдет всю доступную информацию, которая есть в гугле.
Естественно гугл это не единственный пример экосистемы сервисов, которые раскрывают о пользователе всё, что можно, а так же не единственный пример экосистемы в которой на один аккаунт завязаны все остальные сервисы.
Яндекс берет пример, но при этом все таки старается обезопасить пользователя. На схеме ниже представлена связка сервисов яндекса
Не во всех этих сервисах можно по никнейму пользователя и почте получить его профиль, но вместе с тем, они используют некий набор идентификаторов, допустим логин или внутренний айдишник и PublicID. И по этим идентификаторам так или иначе можно из одного сервиса выйти на другой.
Как пример, ребята из HowToFind в ходе исследования зарепортили уязвимость в Яндекс Дзен. Они нашли просто в исходном коде PublicID создателя статей на Дзене.
Не останавливаясь на яндексе, давайте подумаем о том, что с нами всегда – это наши телефоны. У всего этого тоже присутствуют экосистемы сервисов и чаще всего прямо скажем они не самого высокого качества. В ходе исследований были найдены ряд интересных вещей, таких как например восстановления доступа у одного из производителей, который раскрывает все электронные ящики и номера телефонов. Плюс модели устройств, в которые вы входили и точки доступа wifi, к которым вы хотя бы раз подключались. По точкам вайфая можно определить примерный ареал обитания юзера, просто пользуясь картами.
Второй производитель позволяет получить уникальные идентификаторы, так еще и на других сервисах позволяет запрашивать огромными массивами информацию о пользователе просто зная UserID.