PWNED: Отличная идея, ребята. Давайте хранить все данные в Excel-файле со слабой парольной защитой. — theregister.com
PWNED Снова здравствуйте! С вами PWNED — еженедельная колонка, в которой мы рассказываем о приключениях IT-исследователей, нашедших собственную зыбучую трясину и с радостью в нее прыгнувших. История этой недели повествует о хранении конфиденциальной информации в крайне уязвимом месте и последующем недостаточном ее обеспечении защитой.
Эта история стала достоянием общественности благодаря Станиславу Казанову, руководителю стратегических практик в Innowise, фирме по разработке программного обеспечения. Несколько лет назад Казанова и его команду наняли для проведения аудита соответствия требованиям и архитектуры данных в финтех-стартапе, руководство которого инвестировало более 1 миллиона долларов в разработку системы безопасности «военного уровня», включающей биометрическую многофакторную аутентификацию (MFA), обнаружение конечных точек и массу физических мер безопасности.
В ходе аудита Казанов вошел на сайт SharePoint компании и обнаружил на общекорпоративном интранете папку под названием «DevOps_Handoff», доступную любому сотруднику. Внутри этой папки находилась электронная таблица с крайне туманным и обманчивым именем файла: Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx. Очевидно, такое именование должно было сбить с толку любого потенциального хакера.
Из хороших новостей: файл Excel был защищен паролем. Так что, по крайней мере, это что-то, но действительно ли была обеспечена серьезная защита?
Когда Казанов спросил у ведущего инженера пароль, тот так смутился, что уставился в пол и пробормотал ответ: «Это [название компании] + [год]». Мы не знаем реального названия компании, но скажем, что это была Contoso. Таким образом, пароль должен был быть contoso2026. Это не совсем «admin123», но достаточно близко, чтобы угадать.
Ведущий инженер объяснил Казанову причину существования этого файла. По всей видимости, внутренняя DevOps-команда и внешняя команда DBA не смогли договориться о том, какой менеджер паролей корпоративного уровня использовать. Чтобы «временно» разрешить этот спор, они выгрузили учетные данные корневой базы данных и основные ключи AWS IAM в эту электронную таблицу, которая просуществовала целых восемь месяцев к тому моменту, когда наш герой ее обнаружил.
Наша история на этом заканчивается. Мы предполагаем, что эта проблема была решена после вмешательства Казанова и до того, как случилась беда. Однако это показывает, что разногласия по поводу того, как защищать ресурсы, могут привести к опасным компромиссам.
В данном случае решающее слово о том, какого менеджера паролей использовать подрядчикам и им самим, должно было остаться за внутренней DevOps-командой. Ни при каких обстоятельствах им не следовало допускать, чтобы этот конфликт привел к помещению секретов в электронную таблицу, даже если эта таблица имела надежную парольную защиту.
Самый базовый принцип кибербезопасности — предоставлять индивидуальный доступ и учетные данные только тем, кому это действительно необходимо. Но здесь файл находился в интранете, доступном всем сотрудникам и даже подрядчикам вроде Казанова. Поскольку это была финтех-фирма, задействованные данные могли касаться миллионов или даже миллиардов долларов денег людей. Это серьезная ситуация, и любой, кто настолько небрежен в вопросах безопасности, не заслуживает распоряжаться ни центом активов или транзакций.
Есть история о том, как кто-то оставил огромную дыру в своей сети? Поделитесь ею с нами по адресу pwned@sitpub.com. Анонимность гарантируется по запросу. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Avram Piltch