На днях решил заказать еду в достаточно крупной сети ресторанов SushiStore (74 точки в Москве и МО), которая делает довольно неплохие суши. Однако при попытке залогиниться на сайте столкнулся с тем, что SMS с кодом подтверждения перестал приходить. Попробовал отправить код повторно несколько раз, а потом написал в службу поддержки. В поддержке мне ответили, что в качестве кода подтверждения необходимо вводить четыре последние цифры Вашего номера телефона. Да-да, Вы не ослышались, ВАШЕГО номера телефона! Посмотрев более внимательно на форму входа, я действительно увидел соответствующую инструкцию:
Я не мог поверить своим глазам, но все‑таки ввел сначала свой номер телефона, а потом четыре его последние цифры, и к моему удивлению незамедлительно попал в свой личный кабинет. Тут моя челюсть просто отпала:
Если кто не понял, поясню — для входа в личный кабинет на сайте используется по‑сути только публично известная информация — Ваш номер телефона. Нет никаких секретов (паролей), никакого второго фактора. Таким образом, если кто‑то знает Ваш номер телефона, то он может войти в Ваш личный кабинет и узнать следующую персональную информацию о Вас:
Ваше имя,
Ваш E‑Mail,
Ваши физические адреса, куда Вы заказываете суши,
Всю историю Ваших заказов, что может частично раскрывать Ваше финансовое состояние.
Если пойти несколько дальше, то написать несложную программу, которая на основе имеющейся базы Российских номеров телефонов (или методом перебора) выгрузит всю базу данных клиентов компании с их персональными данными не составит особого труда.
Уведомление об уязвимости
Обнаружив данное вопиющее нарушение (а возможно и федеральное преступление) я незамедлительно написал в компанию через чат обратной связи. Оператор просто проигнорировал мое сообщение и ничего не ответил. В 13:40 первого дня я нашел на сайте компании E‑Mail адрес отдела сотрудничества — avk@sushistore.ru (это был единственный наиболее подходящий адрес в разделе контактов) и попросил связать меня с руководителем компании. В 14:45 мне пришло ответное письмо (судя по всему из маркетингового отдела компании) с просьбой прислать подробную информацию. В 15:29 я выслал подробную информацию с описанием уязвимости. В 15:44 мне пришел ответ с устной благодарностью и обещанием передать информацию в IT‑отдел. Сейчас идёт уже второй день, время на часах 17:05. т. е. с момента подсветки уязвимости прошло уже 26 часов, а компания не предприняла никаких действий, чтобы устранить её.
Учитывая как безалаберно и несерьезно компания относится к персональным данным своих клиентов, я принял решение опубликовать эту информацию публично, чтобы пользователи могли собственноручно обезопасить свои данные путем удаления их с сайта.
Рекомендации к действию
Если Вы являетесь пользователем компании SushiStore, то я настоятельно рекомендую незамедлительно зайти в свой личный кабинет и удалить все свои персональные данные.
Также в качестве общей рекомендации могу посоветовать следующее:
внимательно относитесь к тому, где Вы оставляете свои персональные данные, если сервис не вызывает доверия, то лучше этого вообще не делать,
оставляйте только минимум своих данных. Если это не нарушает закона и договоров, используйте обфусцированные данные, где это возможно,
никогда не используйте для регистрации публично известные номера телефонов, а лучше заведите себе отдельный номер телефона и используйте его исключительно для регистраций,
используйте мультифактор везде где это возможно,
если есть возможность, заводите себе отдельные почтовые ящики для различных сервисов,
всегда используйте уникальные пароли для каждого отдельного сервиса.
Причины уязвимости
На основе комментариев решил высказать свое предположение касательно причин возникновения уязвимости. На сайте действительно раньше работала отправка SMS, но видимо сломалась. Компания же не придумала ничего умнее, чем просто открыть доступ к данным пользователям всем подряд, чтобы не терять продажи. т. е. компания осознанно поставила свои финансовые интересы перед интересами пользователей.
Оставайтесь на безопасной стороне и всегда будьте начеку!
Комментарии (25)
vikarti
00.00.0000 00:00+4А то IT-отдел не знает. Такая реализация не сама ж завелась.
Интересно — хотя бы 60 тысяч с SushiStore возьмут? Или выяснится что автор статьи — украинский хакер ?(или гондурасский хакер на службе украины)
Areso
00.00.0000 00:00+7SushiStore, конечно, чудаки, но хорошим тоном является 30 дней между сообщением об уязвимости и раскрытием.
fominslava Автор
00.00.0000 00:00Да, Вы правы. Однако в данном случае дыра слишком явная. За 30 дней базу 100% сольют, а так есть шанс, что руководство закроет дыру оперативно.
dopusteam
00.00.0000 00:00+1За 30 дней базу 100% сольют
Это имело бы смысл, если бы уязвимость появилась вчера
AlexeyK77
00.00.0000 00:00+2если б вы не написали статью через два дня, то никто бы и не слил. а так - сольют.
AlexeyK77
00.00.0000 00:00+9Ни одна компания такого рода проблемы за два дня не может устранить, хотя бы потому, что только на внутреннюю переписку уйдет несколько дней. А потом еще общение с внешним вендором - разработчиком сайта, а потом разработка, потом поставка и тестирование релиза и т.п..
В данном случае речь даже не о технической уязвимости, которую вендор исправлять как правило сам и максимально быстро, а об уязвимости в бизнес-логике, т.е. для закрытия этой дыры надо менять бизнес процесс, вырабатывать новую бизнес-логику. Это не делается ни за два дня, ни даже за две недели-месяц.
Обычно эксперт, выявивший узявимость, работающий в правоввм поле, заранее с оговаривает с организацией некий вменяемый срок на устранение такого рода проблем, после которого вы как частный эксперт публикуете узявимость.
За два дня, мир не меняется...
fominslava Автор
00.00.0000 00:00+4Вы описали какую-то невероятно забюрократизированную организацию. Современные подходы к разработке подразумевают, что компания может делает вплоть до нескольких релизов в день. А уж на то, чтобы закрыть аутентификацию на сайте достаточно буквально изменить одну строчку кода, если есть на то воля руководства.
Вы сначала закройте дыру оперативно, а потом уже можете думать о том что с этим делать и как задачу правильно решать. Просто кому-то важнее прибыль, а не безопасность данных клиентов.
Areso
00.00.0000 00:00+2Эм, это только если ежедневный релиз этого программного продукта уже был отстроен.
Вряд ли это про Сушильню...
fominslava Автор
00.00.0000 00:00+1В данном случае всё ещё проще. У Сушильни точно не может быть десять уровней согласований и описанной Вами бюрократии, это не Майкрософт и не гос. корпорация. Руководителю компании достаточно просто попросить сотрудника-разработчика (или подрядчика) закрыть аутентификацию напрямую. Учитывая критичность ситуации, это вопрос часа работы максимум с учетом всех согласований и необходимых действий.
AlexeyK77
00.00.0000 00:00+3с точки зрения бизнеса, то что вы описали, это не дыра )). Дыра, это когда доходы падают, или прокурор пришел :)
Но даже если вдруг и решат закрыть проблему, то есть договорные отношения с поставщиком - софтовой компанией. А любые договорные отношения это всегда документооборот, счет, поставка, акт выполненных работ.В следующий раз, лучше не горячиться с сенсациями, мир вокруг "безопасности" не крутится вообще, а просто медленно и системно делать дело, помогая сделать мир лучше, не ожидая, что мир будет меняться быстро.
luckybet100
00.00.0000 00:00+1Простите, но как человек хорошо знакомый с аутсорсом. А вредил сушильня имеет свой it отдел:
- далеко не всегда аутсорс, даже хороший, может сделать что-то в тот же день. Тем более, когда это доработка логики
- закрыть регистрацию = простой всей доставки на что бизнес не готов и требовать это не разумно, учитывая, что до этого сайт висел и без Вашей статьи на хабре за 2-3 дня уязвимость более критической бы не стала
- реализовать вход через номер телефона, даже у нормального разработчика может отнять пару дней с учетом того, что необходимо выбрать смс шлюз, зарегистрировать там аккаунт, вероятно переделать и бек и фронт
- публикации статьи спустя 26 часов, что чуть больше суток является совсем некорректным поведением. Особенно учитывая наличие хоть какой-то реакции. + Вы на самом деле даже не ждали суток (вряд ли статья была написана за 2 часа), так что выглядит как попытка похайпиться. Если Вы хотели позаботиться о персональных данных - сделали все, чтобы на одну слитую базу ПД стало больше. Хабраэффект будет налицо
hyperwolf
00.00.0000 00:00+4Да нет, это нормальная практика для любой компании, где работает больше 10 человек. А вот вы поступили не красиво дважды: во-первых, не обозначили компании срок, в течении которого вы расскажете об уязвимости (и да, как бы стандарт 30 дней), во-вторых теперь базу точно сольют.
Подход, где делается несколько релизов в день не означает, что за час выкатят хотфикс в прод, на него банально может не быть ресурсов/людей/времени. У этого магазина суши может и айти отдела своего нет толком, а сайт пилит какая-нибудь компания на аутсорсе и ей с большего безразлично на ваши гибкие методологии разработки и time to market.
vikarti
00.00.0000 00:00Я вот вспоминаю две конторы финансового плана где работать приходилось:
- №1 — в субботу "небольшая проблема" на проде с мобилкой, проблема простая, диагностика понятна. CTO заказчика дергает меня в общем чате, через несколько часов с CI сборка уходит в PlayStore. Но при этом — у меня было полное право сказать "ждите понедельника"(и ждали бы — больше некому).
- №2 (значительно крупнее №1). экстренный релиз посреди недели — он вообще будет если либо креш в 100% случаях и увидят это чуть менее чем все и покажут по ТВ(ну или по конкретной фиче затронуто многое и бизнес убедил что ну край надо) и все равно — поиск, ревью патча, согласованная, постепенная раскатка. За час не выкатят точно, если все согласны что да надо фиксить СРОЧНО и никак иначе — ну скорее день будет. Если увидят не все — фиксить в лучшем случае в этом спринте будут а пользователи через несколько недель увидят. А на всякий случай — есть механизм отключения фичей.
hyperwolf
00.00.0000 00:00А тут небольшое помещение, как мне кажется,, кухня, люди крутят суши. Вся айти-обвязка там где-то сбоку и живет по остаточному принципу. Если вообще не на аутсорсе. Так-то я знаю как это работает в айти-компаниях, но те компании не суши крутят с доставкой по городу.
MountainGoat
00.00.0000 00:00+2А ещё компания может сначала выключить сервис, в котором такая дыра, а потом уже месяц общаться с контрагентами, менеджерами и коучами. Но они этого не будут делать, потому что убытки - а на утечку данных плевать, это не убытки.
Если бы им грозил штраф в размере 100% оборота от дня обнаружения проблемы до дня устранения - поверьте, они бы за день хоть весь сервис перестроили.
Gudd-Head
00.00.0000 00:00Ваше имя, Ваш E‑Mail
Таки не конкретно Ваше имя, а то имя, которое было указано при регистрации / в профиле пользователя. Как и Е-маил.
KillJ0y
00.00.0000 00:00По частным компаниям такое сплош и рядом, в разной, степени раздолбайства. Например есть компания у неё есть серт фсб на работу с скзи, клиенты присылают хорошие сканы паспорта, снилс, инн, а так же стс, птс, Vin и остальную информацию, как вы думаете как хранятся эти документы? (По закону они должны 5 лет храниться)) просто в открытом виде на компе, ни какой защиты нет, да комп за nat в виде домашнего роутера, как бы все. Увидел ужаснулся, и всех все устраивает, данные хранятся? Хранятся! Информация в публичном доступе? Нет! Все, жопа прикрыта деньги идут. Были даны рекомендации по закрытию такого безобразия, однако данные просто были удалены на win машине и перенесены на локальный nextcloud, а защиты там нет, фаервол просто открыт. Linux сервер кто то настроил и ушел, обновлений нет, настроить не могут, но работает же, и так сойдёт
dartraiden
Судя по «отправить код повторно», у них действительно отправлялся одноразовый код в смс. Когда-то. Видимо, по какой-то причине они не могут больше отправлять код и прикрутили такой вот временный костыль, а, как известно, нет ничего более постоянного, чем временное.
С точки зрения законодательства эта совокупность не является персональными данными, т.к. не позволяет однозначно идентифицировать конкретного человека. То есть, я могу хоть сейчас дать вам имя, адрес эл. почты и адрес куда я заказываю суши, но чтобы меня однозначно идентифицировать, вам понадобятся дополнительные действия.
Да, этой информацией можно обогатить другие базы, чтобы однозначно сопоставить запись с конкретным лицом, но вот тогда уже эта совокупность и будет являться персональными данными.
Это всё к тому, что пассажи про «федеральное преступление» тут вообще ни к месту.
fominslava Автор
Я не эксперт в юридических вопросах, но в законе (https://www.consultant.ru/cons/cgi/online.cgi?from=370272-0&req=doc&rnd=ECcSsQ&base=LAW&n=422875#VYdWpXT4y0JtvT581) написано:
foxyrus
С точки зрения нашего законодательства даже куки (!) являются перс данными (это конечно, когда надо кого то нужного прижать).
nochkin
Если по имени и физическому адресу нельзя идентицифировать человека, то как тогда можно? По мне, так имя и адрес уже достаточно. По-хорошему, одного имени уже достаточно.