Практически каждый день «Хакер» пишет о масштабных и не очень утечках данных. «Течет» откуда только можно, и последствия бывают самыми разными. Сегодня я постараюсь рассказать и показать, как легко злоумышленники могут получить доступ к обширным массивам всевозможных данных.
Таким образом, одной из основных причин утечки данных служит криворукость администраторов небезопасная конфигурация СУБД, оставленная в результате невнимательности или же просто недостатка знаний.
База данных — это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе. База данных обычно управляется системой управления базами данных (СУБД). Данные вместе с СУБД, а также приложения, которые с ними связаны, называются системой баз данных, или, для краткости, просто базой данных.
Стоимость восстановления или покупки украденной базы данных может немного варьировать, так как курс биткоина к доллару часто колеблется. Как правило, выкуп равен примерно 500 долларам в криптовалюте, независимо контента БД и пострадавшего сайта. Из-за этого журналисты полагают, что злоумышленники не анализируют взломанные и украденные БД, и процесс полностью автоматизирован.
Как же можно взломать и получить доступ к любому сайту?
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCT
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:
GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost'; GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
Точек вхождения в чужую базу MySQL не так уж и много по сравнению с другими СУБД: SQL Injection, поиск логинов и паролей на GitHub, брутфорс, уязвимость к багам из паблика. К методам постэксплуатации можно еще дополнительно отнести повышение привилегий, DoS-атаки, применение триггеров и хранимых процедур. Правда, отдельные из них относятся к частным случаям, которые нечасто можно встретить либо для которых нужны очень специфичные условия.