Channel: CISO on fire
Про взлом Uber
На днях получил такое сообщение в одном из своих тикетов на Hackerone, который я отправлял 5 лет назад в баг-баунти программу Uber:
Некий хакер взломал Uber и их внутренние системы, и разослал это сообщение во все репорты в их Bug Bounty программе.
Он указал в нем свой телеграм-контакт, поэтому с ним сразу связались, и он охотно отвечал на вопросы.
Как происходил взлом, со слов самого хакера:
1) он засоциалил сотрудника Uber и получил доступ в VPN
2) просканил сеть и нашел сетевую шару, на которой лежали Powershell-скрипты
3) в одном из скриптов нашелся захардкоженный админский логин и пароль к системе управления доступами Thycotic
4) через эту систему он получил креденшелы к контроллеру домена, Duo, OneLogin, AWS, Gsuite, админке Slack - ко всем критическим системам компании, и, потенциально, ко всем их данным.
5) дальше он разослал сообщения во все репорты в Hackerone и сотрудникам в Slack
Что в этой истории примечательного.
1. Сама атака очень простая и "глупая"
Как именно был получен доступ к VPN - до конца неясно. На одном из скриншотов хакер признается, что спамил одного из сотрудников пуш-запросами "подтверди доступ с нового устройства", и затем написал ему в Whatsapp, притворившись техподдержкой, и попросил пуш-запрос подтвердить.
Но непонятно, был ли это единственный фактор, необходимый для доступа (в таком случае это явная уязвимость), или же это был второй фактор, а первый был украден как-то еще.
Впрочем, если смотреть с точки зрения защиты от этой атаки, то это не так важно. Потому что когда в компании работают тысячи (в случае Uber - десятки тысяч) сотрудников, то доступ в VPN вообще нельзя считать сколь-либо надежным рубежом защиты. Просто потому, что вероятность того, что в каждый конкретный момент времени у кого-то из сотрудников на компьютере есть малварь - близка к 100%.
2. Защититься от таких атак сложно
Можно проследить цепочку атаки дальше, от большинства проблем защититься если и можно, то либо не очень надежным способом, либо же надежное решение проблемы будет стоять достаточно высоко в пирамиде хотелок безопасников, и традиционно не считается "must have" необходимостью
3. Мотивация хакера непонятна
Кажется, что он ничего не получил, кроме веселья и внимания. Пишут, что хакеру 18 лет.
Это достаточно необычно. Гораздо чаще такие хакеры:
- либо являются преступниками и пытаются украсть данные и заработать преступным путем. И не пишут публично о взломе. А у Uber явно было, что красть.
- либо, если у компании есть работающая баг баунти программа (у Uber она есть) - хакер может принести такой репорт туда и получить свои $20-50тыс вознаграждения
4. Следствие из 3 предыдущих пунктов - нам всем сильно "повезло", что эта история стала публичной
Если грубо, то на каждого такого шутника, пробившего периметр и получившего доступ ко всем данным Uber-а, будет 5 багхантеров, сделавших то же самое, и не отказавшихся от вознаграждения, и 5 преступников, которые выкачают молча все что смогут, и про которых никто не узнает. Иными словами: взломать легко, защититься от такого взлома сложно, кто еще украл наши данные - неизвестно. И даже хорошая security-программа в мирового уровня компании не дает никаких гарантий
5. Поднятая шумиха и количество слитых внутренних скриншотов с подтверждениями взлома уже не позволит Уберу отмазаться и сделать вид, что ничего не было. Что будет дальше - сильно зависит от того, какие данные хакер успел слить.
Вполне вероятно, что данные пользователей конкретно сейчас не пострадали. Тогда Убер может сказать, что "подтверждений утечки данных нет". Могут вызвать кого-то из топов в конгресс и попросить повторить это под присягой. И вся история закончится плюс-минус ничем.
Если же хакер слил, например, данные платежных карт, и по какой-то причине Убер это признает - банки могут начать блокировать привязанные к уберу карты, тогда пострадает выручка и доля Убера на конкурентных рынках. Но такой сценарий скорее маловероятен.
Будем наблюдать
На днях получил такое сообщение в одном из своих тикетов на Hackerone, который я отправлял 5 лет назад в баг-баунти программу Uber:
UBER HAS BEEN HACKED (domain admin, aws admin, vsphere admin, gsuite SA) AND THIS HACKERONE ACCOUNT HAS BEEN ALSO
my telegram: <...>Некий хакер взломал Uber и их внутренние системы, и разослал это сообщение во все репорты в их Bug Bounty программе.
Он указал в нем свой телеграм-контакт, поэтому с ним сразу связались, и он охотно отвечал на вопросы.
Как происходил взлом, со слов самого хакера:
1) он засоциалил сотрудника Uber и получил доступ в VPN
2) просканил сеть и нашел сетевую шару, на которой лежали Powershell-скрипты
3) в одном из скриптов нашелся захардкоженный админский логин и пароль к системе управления доступами Thycotic
4) через эту систему он получил креденшелы к контроллеру домена, Duo, OneLogin, AWS, Gsuite, админке Slack - ко всем критическим системам компании, и, потенциально, ко всем их данным.
5) дальше он разослал сообщения во все репорты в Hackerone и сотрудникам в Slack
Что в этой истории примечательного.
1. Сама атака очень простая и "глупая"
Как именно был получен доступ к VPN - до конца неясно. На одном из скриншотов хакер признается, что спамил одного из сотрудников пуш-запросами "подтверди доступ с нового устройства", и затем написал ему в Whatsapp, притворившись техподдержкой, и попросил пуш-запрос подтвердить.
Но непонятно, был ли это единственный фактор, необходимый для доступа (в таком случае это явная уязвимость), или же это был второй фактор, а первый был украден как-то еще.
Впрочем, если смотреть с точки зрения защиты от этой атаки, то это не так важно. Потому что когда в компании работают тысячи (в случае Uber - десятки тысяч) сотрудников, то доступ в VPN вообще нельзя считать сколь-либо надежным рубежом защиты. Просто потому, что вероятность того, что в каждый конкретный момент времени у кого-то из сотрудников на компьютере есть малварь - близка к 100%.
2. Защититься от таких атак сложно
Можно проследить цепочку атаки дальше, от большинства проблем защититься если и можно, то либо не очень надежным способом, либо же надежное решение проблемы будет стоять достаточно высоко в пирамиде хотелок безопасников, и традиционно не считается "must have" необходимостью
3. Мотивация хакера непонятна
Кажется, что он ничего не получил, кроме веселья и внимания. Пишут, что хакеру 18 лет.
Это достаточно необычно. Гораздо чаще такие хакеры:
- либо являются преступниками и пытаются украсть данные и заработать преступным путем. И не пишут публично о взломе. А у Uber явно было, что красть.
- либо, если у компании есть работающая баг баунти программа (у Uber она есть) - хакер может принести такой репорт туда и получить свои $20-50тыс вознаграждения
4. Следствие из 3 предыдущих пунктов - нам всем сильно "повезло", что эта история стала публичной
Если грубо, то на каждого такого шутника, пробившего периметр и получившего доступ ко всем данным Uber-а, будет 5 багхантеров, сделавших то же самое, и не отказавшихся от вознаграждения, и 5 преступников, которые выкачают молча все что смогут, и про которых никто не узнает. Иными словами: взломать легко, защититься от такого взлома сложно, кто еще украл наши данные - неизвестно. И даже хорошая security-программа в мирового уровня компании не дает никаких гарантий
5. Поднятая шумиха и количество слитых внутренних скриншотов с подтверждениями взлома уже не позволит Уберу отмазаться и сделать вид, что ничего не было. Что будет дальше - сильно зависит от того, какие данные хакер успел слить.
Вполне вероятно, что данные пользователей конкретно сейчас не пострадали. Тогда Убер может сказать, что "подтверждений утечки данных нет". Могут вызвать кого-то из топов в конгресс и попросить повторить это под присягой. И вся история закончится плюс-минус ничем.
Если же хакер слил, например, данные платежных карт, и по какой-то причине Убер это признает - банки могут начать блокировать привязанные к уберу карты, тогда пострадает выручка и доля Убера на конкурентных рынках. Но такой сценарий скорее маловероятен.
Будем наблюдать
Яндекс рассказал подробности про историю с утечкой данных Яндекс.Еды в начале этого года.
Вкратце, после приобретения Яндексом в 2017 году этого сервиса, который раньше назывался FoodFox, некоторые сервера не были перевезены в инфраструктуру Яндекса, а остались в старом хостинге. Один из таких серверов и был взломан хакерами. Или даже сам хостинг целиком, это не совсем понятно из рассказа. Изначально Яндекс сообщал о том, что это была утечка по вине инсайдера, сейчас они признали, что та версия была ошибочной.
Хакеры получили доступ и выложили в паблик базу всех заказов, включая телефон, адрес и сумму заказа.
Какие здесь могут быть выводы:
1) Яндекс и ребята большие молодцы, что рассказали
2) Интересный формат для корп. коммуникаций - интервью с экспертами компании в видео-подкасте. Сейчас все смотрят ютуб, а большинство компаний все еще ограничиваются пресс-релизами и статьями на хабре
3) Проблема Shadow IT становится все более актуальной. Когда у компании есть свои сервера, облачная инфраструктура, партнерские проекты, сторонние SaaS-ы, а еще все то же самое могут использовать разработчики самостоятельно без ведома ИБ.
Даже просто найти все это и собрать список - уже проблема само по себе. Недостаточно защищать свою инфраструктуру и свой "периметр", взломают вас всегда через самое дырявое место
4) Большинство взломов остаются неизвестными публике, потому что данные тихонько используются годами для извлечения выгоды. Эта тенденция поменялась в России в этом году, теперь часто украденное публикуют сразу. Но сколько взломов остаются неизвестными - мы все равно не знаем
5) Никогда не верьте, когда компания говорит, что взлом произошел по вине инсайдеров. Это почти всегда либо обман, либо добросовестное заблуждение. Для этого есть несколько причин (дальше не про Яндекс и этот случай, а по моему опыту в целом):
- это всегда первая реакция админов внутри, они начинают предполагать "крысу", как только видят хоть сколько-то продвинутую атаку. Всегда кажется, что сторонний человек не смог бы сам разобраться с такой сложной системой, как наша
- расследовать инцидент безопасности так, чтобы действительно удалось раскрутить всю цепочку - очень сложно, особенно если не тренироваться и не готовиться к этому заранее. Бывает так, что технари не находят никаких следов, и доносят версию про инсайдера своему руководству
- это психологически комфортная версия, что это не у нас проблема, а нашелся инсайдер
- кажется, что это спокойнее воспринимается обществом, что это не компания дырявая, а человеческий фактор, с которым как бы ничего не поделаешь
При этом в 95% случаев никаких "крыс" нет, а есть хакеры, которые достаточно долго посидели внутри, изучили инфраструктуру, документацию, исходники и т.д. А даже в тех редких случаях, когда действительно виноват инсайдер - обычно есть технические предпосылки к этому, например, слишком широкие доступы для сотрудников службы поддержки в админке.
Это именно про взломы и утечки. Если инцидент касается денежного фрода, то вероятность того, что замешаны инсайдеры может быть несколько выше.
Само интервью тут https://www.youtube.com/watch?v=rymoPIkHJjQ
Вкратце, после приобретения Яндексом в 2017 году этого сервиса, который раньше назывался FoodFox, некоторые сервера не были перевезены в инфраструктуру Яндекса, а остались в старом хостинге. Один из таких серверов и был взломан хакерами. Или даже сам хостинг целиком, это не совсем понятно из рассказа. Изначально Яндекс сообщал о том, что это была утечка по вине инсайдера, сейчас они признали, что та версия была ошибочной.
Хакеры получили доступ и выложили в паблик базу всех заказов, включая телефон, адрес и сумму заказа.
Какие здесь могут быть выводы:
1) Яндекс и ребята большие молодцы, что рассказали
2) Интересный формат для корп. коммуникаций - интервью с экспертами компании в видео-подкасте. Сейчас все смотрят ютуб, а большинство компаний все еще ограничиваются пресс-релизами и статьями на хабре
3) Проблема Shadow IT становится все более актуальной. Когда у компании есть свои сервера, облачная инфраструктура, партнерские проекты, сторонние SaaS-ы, а еще все то же самое могут использовать разработчики самостоятельно без ведома ИБ.
Даже просто найти все это и собрать список - уже проблема само по себе. Недостаточно защищать свою инфраструктуру и свой "периметр", взломают вас всегда через самое дырявое место
4) Большинство взломов остаются неизвестными публике, потому что данные тихонько используются годами для извлечения выгоды. Эта тенденция поменялась в России в этом году, теперь часто украденное публикуют сразу. Но сколько взломов остаются неизвестными - мы все равно не знаем
5) Никогда не верьте, когда компания говорит, что взлом произошел по вине инсайдеров. Это почти всегда либо обман, либо добросовестное заблуждение. Для этого есть несколько причин (дальше не про Яндекс и этот случай, а по моему опыту в целом):
- это всегда первая реакция админов внутри, они начинают предполагать "крысу", как только видят хоть сколько-то продвинутую атаку. Всегда кажется, что сторонний человек не смог бы сам разобраться с такой сложной системой, как наша
- расследовать инцидент безопасности так, чтобы действительно удалось раскрутить всю цепочку - очень сложно, особенно если не тренироваться и не готовиться к этому заранее. Бывает так, что технари не находят никаких следов, и доносят версию про инсайдера своему руководству
- это психологически комфортная версия, что это не у нас проблема, а нашелся инсайдер
- кажется, что это спокойнее воспринимается обществом, что это не компания дырявая, а человеческий фактор, с которым как бы ничего не поделаешь
При этом в 95% случаев никаких "крыс" нет, а есть хакеры, которые достаточно долго посидели внутри, изучили инфраструктуру, документацию, исходники и т.д. А даже в тех редких случаях, когда действительно виноват инсайдер - обычно есть технические предпосылки к этому, например, слишком широкие доступы для сотрудников службы поддержки в админке.
Это именно про взломы и утечки. Если инцидент касается денежного фрода, то вероятность того, что замешаны инсайдеры может быть несколько выше.
Само интервью тут https://www.youtube.com/watch?v=rymoPIkHJjQ
Сегодня главная новость - утечка исходников Яндекса. Утекло в паблик очень много - 44 Гб в сжатом виде, 83 репозитория.
Дальше по порядку, самое интересное в конце.
1. Утекли исходники почти всех продуктов. Там есть и Почта, и Такси, и Диск, и Алиса. Врядли эти исходники кто-то сможет использовать напрямую, этого точно не стоит бояться.
2. Пользовательских данных, в первом приближении, там нет. В том смысле, что это именно исходники, конфиги, но не базы данных
3. Часто утечка исходников сильно вредит безопасности продукта, потому что там бывают захардкоженные секреты и простые уязвимости. На первый взгляд, здесь этого тоже нет, по крайней мере в сравнении с масштабом утечки. Секреты не хранятся в коде напрямую, а подтягиваются откуда-то еще - это очень правильно, так и нужно всегда делать.
4. Очень много самописных внутренних инструментов, много документации. Интересно для изучения, чтобы понимать как работают большие компании и их IT-инфраструктура. Кажется, что в Яндексе есть сильный перевес в пользу "напишем сами" даже тогда, когда другие компании обошлись бы опенсорсом.
5. Конечно, интересен репозиторий security 🙂 Там тоже внутренние инструменты, всевозможные сканеры, разбиралки тикетов, все на достаточно продвинутом уровне.
6. Дальше еще интереснее. Яндекс массово использует Телеграм в качестве рабочего мессенджера. В файлах есть куча ссылок на чатики в телеграме, по которым можно было прийти и вступить. Сразу после новости о сливе большую часть из них подчистили, но не все. Использование Телеграма - большая проблема и боль для безопасности. Правильный выход - это конечно использование корпоративного мессенджера с полным запретом личных. Но у них тоже есть свои недостатки, телеграм просто очень удобный. В Яндексе используют специального телеграм-бота, которого добавляют в чатики и он следит, чтобы там не было чужаков. Но понятно, что работает это только в тех чатиках, куда бота не забыли добавить.
7. В репозитории Алисы тоже много интересного. Именно самой говорящей модели Алисы вроде нет, но есть много разных скриптов для ее обучения, фрагментов обучающих данных и т.п. Есть выборки реальных (анонимных) запросов пользователей к Алисе, очень интересные. На скриншоте фрагмент файла с реальными призывами к Алисе замолчать. Его можно растащить на мемы буквально целиком
8. В репозитории Почты есть код, который занимается разметкой данных из писем. В том числе анализируются письма с подписками на разные онлайн-сервисы, письма с чеками. Зачем именно - неясно, возможно Яндекс так мониторит конкурентов по рынку?
9. Подход с "монорепой", когда весь код большой компании лежит в одном большом репозитории имеет и свои плюсы и минусы. Когда много сотрудников имеют доступ сразу ко всему - с одной стороны это очень удобно, а с другой, утечка становится вопросом времени. Надо быть к ней готовыми.
10. Данных очень много, это все еще только предстоит изучать. Что делать Яндексу? Да ничего, выпустить пресс-релиз, что исходники старые, данные пользователей в безопасности, взлома не было, виноват инсайдер 🙂 Ну и старательно найти и инвалидировать все секреты.
11. Можно еще сделать красивый жест, выложить официально в опенсорс часть внутренних инструментов и библиотек. Хуже уже точно не будет, а лучше будет.
@ciso_on_fire
Дальше по порядку, самое интересное в конце.
1. Утекли исходники почти всех продуктов. Там есть и Почта, и Такси, и Диск, и Алиса. Врядли эти исходники кто-то сможет использовать напрямую, этого точно не стоит бояться.
2. Пользовательских данных, в первом приближении, там нет. В том смысле, что это именно исходники, конфиги, но не базы данных
3. Часто утечка исходников сильно вредит безопасности продукта, потому что там бывают захардкоженные секреты и простые уязвимости. На первый взгляд, здесь этого тоже нет, по крайней мере в сравнении с масштабом утечки. Секреты не хранятся в коде напрямую, а подтягиваются откуда-то еще - это очень правильно, так и нужно всегда делать.
4. Очень много самописных внутренних инструментов, много документации. Интересно для изучения, чтобы понимать как работают большие компании и их IT-инфраструктура. Кажется, что в Яндексе есть сильный перевес в пользу "напишем сами" даже тогда, когда другие компании обошлись бы опенсорсом.
5. Конечно, интересен репозиторий security 🙂 Там тоже внутренние инструменты, всевозможные сканеры, разбиралки тикетов, все на достаточно продвинутом уровне.
6. Дальше еще интереснее. Яндекс массово использует Телеграм в качестве рабочего мессенджера. В файлах есть куча ссылок на чатики в телеграме, по которым можно было прийти и вступить. Сразу после новости о сливе большую часть из них подчистили, но не все. Использование Телеграма - большая проблема и боль для безопасности. Правильный выход - это конечно использование корпоративного мессенджера с полным запретом личных. Но у них тоже есть свои недостатки, телеграм просто очень удобный. В Яндексе используют специального телеграм-бота, которого добавляют в чатики и он следит, чтобы там не было чужаков. Но понятно, что работает это только в тех чатиках, куда бота не забыли добавить.
7. В репозитории Алисы тоже много интересного. Именно самой говорящей модели Алисы вроде нет, но есть много разных скриптов для ее обучения, фрагментов обучающих данных и т.п. Есть выборки реальных (анонимных) запросов пользователей к Алисе, очень интересные. На скриншоте фрагмент файла с реальными призывами к Алисе замолчать. Его можно растащить на мемы буквально целиком
8. В репозитории Почты есть код, который занимается разметкой данных из писем. В том числе анализируются письма с подписками на разные онлайн-сервисы, письма с чеками. Зачем именно - неясно, возможно Яндекс так мониторит конкурентов по рынку?
9. Подход с "монорепой", когда весь код большой компании лежит в одном большом репозитории имеет и свои плюсы и минусы. Когда много сотрудников имеют доступ сразу ко всему - с одной стороны это очень удобно, а с другой, утечка становится вопросом времени. Надо быть к ней готовыми.
10. Данных очень много, это все еще только предстоит изучать. Что делать Яндексу? Да ничего, выпустить пресс-релиз, что исходники старые, данные пользователей в безопасности, взлома не было, виноват инсайдер 🙂 Ну и старательно найти и инвалидировать все секреты.
11. Можно еще сделать красивый жест, выложить официально в опенсорс часть внутренних инструментов и библиотек. Хуже уже точно не будет, а лучше будет.
@ciso_on_fire
Алиса Хватит.txt
9.8 MB
Если вы хотели попросить Алису замолчать, но не знали как. То на этих запросах пользователей она точно обучена :)
@ciso_on_fire
@ciso_on_fire
Как узнать, кто добавлял вас в контакты
Все уже знают, что телеграм на днях запустил сторисы.
С ними есть одна интересная особенность, про которую пока мало кто знает
Сначала два простых факта:
1. Telegram показывает вам сторисы тех, кто есть у вас в контактах.
Это понятно, оно так же работает и в инстаграме - там вы видите сторисы тех, на кого подписаны
2. Автор видит, кто посмотрел его сториз. Тоже ничего страшного, в инстаграме работает так же
Но именно из-за сочетания этих факторов появляется интересная уязвимость, а точнее возможность раскрытия данных — вы можете узнать, кто добавил вас в контакты.
Для этого нужно запостить любую сториз, и наблюдать в реальном времени, кто ее посмотрит. Большинство из этих людей будут вашими знакомыми, но не только.
Почему это имеет значение
В отличие от подписок в инстаграме, список контактов в вашем телефоне — это ваша личная секретная информация. Часто люди добавляют туда тех, кем когда-то по каким-либо причинам интересовались.
Вы можете встретить там своих тайных поклонников, эйчаров или сотрудника военкомата 🙂
Итак, как провести эксперимент:
1. Обновить Telegram
2. Купить премиум
3. Опубликовать любую сториз
4. Ждать, пока ваши тайные поклонники ее посмотрят
При этом, важно:
1. Пробовать это скорее, пока разработчики не исправили проблему
2. Тем более, что сейчас сторисы только появились, и люди активно их смотрят. Когда первая волна интереса пройдет, количество зрителей может упасть, а количество авторов сториз вырастет, поэтому эффективность метода упадет
3. Во время эксперимента лучше воздержаться от просмотра чужих сториз. Потому что их авторы тоже увидят вас в списке зрителей, и оттуда в один клик попадут уже на вашу приманку, таким образом вы получите ложные срабатывания. И не писать в крупные чатики, по той же причине
На моем примере. Работа безопасника включает в себя расследование инцидентов — взломов, утечек и тому подобных. Инциденты бывают разные, и для успеха расследования важно использовать все доступные и законные способы получения информации. Эта сфера называется Open-Source Intelligence (OSINT).
Когда нужно найти информацию по какому-то номеру телефона, один из часто используемых трюков такой: мы добавляем номер себе в контакты, и смотрим, как выглядит этот контакт в разных мессенджерах и соцсетях.
Для поиска в соцсетях лучше использовать чистый аккаунт и чистый телефон, и добавлять человека единственным контактом в телефонной книге. Иначе вы не поймете, кого именно вам соцсеть предлагает в рекомендациях — они там не подписаны.
В мессенджерах же обычно мы добавляем номер просто себе в контакты.
Так вот, обновив телеграм, я увидел сторисы сразу нескольких людей, по которым искал информацию за последние годы. А они увидели меня в своем списке зрителей 🙂
Как разработчики Telegram могут исправить проблему?
1. Самое хорошее решение — это показывать вам сторисы не всех контактов, а только тех, с которыми вы переписывались или взаимодействовали за последнее время. Я думаю, что именно это они сделают, потому что это поможет и самой фиче - я хочу видеть истории тех, с кем общаюсь, а они не всегда есть у меня в контактах
2. Самое корректное — это предупреждать юзера о том, что авторы сторисов увидят, что вы ее посмотрели. Это важный принцип в безопасности: юзер должен понимать поведение продукта касаемо любых вопросов privacy
3. Самый простой вариант — скрыть список просмотров. Так делать не нужно, это ухудшит user engagement
4. Еще один хороший вариант — это раскрывать в списке зрителей сторизов только тех, кто с вами общался, а всех остальных скрывать, показывать только их общее количество
@ciso_on_fire
Все уже знают, что телеграм на днях запустил сторисы.
С ними есть одна интересная особенность, про которую пока мало кто знает
Сначала два простых факта:
1. Telegram показывает вам сторисы тех, кто есть у вас в контактах.
Это понятно, оно так же работает и в инстаграме - там вы видите сторисы тех, на кого подписаны
2. Автор видит, кто посмотрел его сториз. Тоже ничего страшного, в инстаграме работает так же
Но именно из-за сочетания этих факторов появляется интересная уязвимость, а точнее возможность раскрытия данных — вы можете узнать, кто добавил вас в контакты.
Для этого нужно запостить любую сториз, и наблюдать в реальном времени, кто ее посмотрит. Большинство из этих людей будут вашими знакомыми, но не только.
Почему это имеет значение
В отличие от подписок в инстаграме, список контактов в вашем телефоне — это ваша личная секретная информация. Часто люди добавляют туда тех, кем когда-то по каким-либо причинам интересовались.
Вы можете встретить там своих тайных поклонников, эйчаров или сотрудника военкомата 🙂
Итак, как провести эксперимент:
1. Обновить Telegram
2. Купить премиум
3. Опубликовать любую сториз
4. Ждать, пока ваши тайные поклонники ее посмотрят
При этом, важно:
1. Пробовать это скорее, пока разработчики не исправили проблему
2. Тем более, что сейчас сторисы только появились, и люди активно их смотрят. Когда первая волна интереса пройдет, количество зрителей может упасть, а количество авторов сториз вырастет, поэтому эффективность метода упадет
3. Во время эксперимента лучше воздержаться от просмотра чужих сториз. Потому что их авторы тоже увидят вас в списке зрителей, и оттуда в один клик попадут уже на вашу приманку, таким образом вы получите ложные срабатывания. И не писать в крупные чатики, по той же причине
На моем примере. Работа безопасника включает в себя расследование инцидентов — взломов, утечек и тому подобных. Инциденты бывают разные, и для успеха расследования важно использовать все доступные и законные способы получения информации. Эта сфера называется Open-Source Intelligence (OSINT).
Когда нужно найти информацию по какому-то номеру телефона, один из часто используемых трюков такой: мы добавляем номер себе в контакты, и смотрим, как выглядит этот контакт в разных мессенджерах и соцсетях.
Для поиска в соцсетях лучше использовать чистый аккаунт и чистый телефон, и добавлять человека единственным контактом в телефонной книге. Иначе вы не поймете, кого именно вам соцсеть предлагает в рекомендациях — они там не подписаны.
В мессенджерах же обычно мы добавляем номер просто себе в контакты.
Так вот, обновив телеграм, я увидел сторисы сразу нескольких людей, по которым искал информацию за последние годы. А они увидели меня в своем списке зрителей 🙂
Как разработчики Telegram могут исправить проблему?
1. Самое хорошее решение — это показывать вам сторисы не всех контактов, а только тех, с которыми вы переписывались или взаимодействовали за последнее время. Я думаю, что именно это они сделают, потому что это поможет и самой фиче - я хочу видеть истории тех, с кем общаюсь, а они не всегда есть у меня в контактах
2. Самое корректное — это предупреждать юзера о том, что авторы сторисов увидят, что вы ее посмотрели. Это важный принцип в безопасности: юзер должен понимать поведение продукта касаемо любых вопросов privacy
3. Самый простой вариант — скрыть список просмотров. Так делать не нужно, это ухудшит user engagement
4. Еще один хороший вариант — это раскрывать в списке зрителей сторизов только тех, кто с вами общался, а всех остальных скрывать, показывать только их общее количество
@ciso_on_fire
HTML Embed Code: