🕵️‍♂️🔐 Эмодзи и SQL-инъекция: как два байта помогли взломать Казначейство США

Пока весь мир готовился к празднованию Нового года, в Министерстве финансов США (US Treasury) царила паника. Оказывается, прямо перед праздниками стало известно, что китайские хакеры успешно проникли в их системы. И причина этого была настолько абсурдной, что её сложно представить даже в голливудском блокбастере про хакеров: всего два невинных байта, «спрятанных» в эмодзи и переданных через базу данных PostgreSQL, взломали систему государственного уровня.

Давайте вместе разберём, как такое вообще могло случиться и почему простая SQL-инъекция до сих пор актуальна.

📌 Что произошло?

30 декабря 2024 года стало известно, что атака на казначейство США прошла через популярный PAM-инструмент (Privileged Access Management - Управление привилегированным доступом) от компании Beyond Trust. Но настоящая причина оказалась глубже: это была уязвимость в PostgreSQL, одной из самых защищённых и изученных open-source баз данных мира.

Причина — в классической SQL-инъекции, которая осталась незамеченной почти десятилетие, спрятавшись в неочевидном месте. Хакеры использовали всего два байта: c0 27. Эти байты выглядят невинно, но кроют в себе хитрый механизм, заставивший PostgreSQL «слепо довериться» некорректным данным и открыть доступ к системе.

⚙️ Технические подробности взлома

Виновником оказался механизм обработки Unicode в PostgreSQL. Вот как это произошло на техническом уровне:

💻 Шаг 1:
Сначала хакеры отправили строку, начинающуюся с байта 0xc0. PostgreSQL воспринял её как начало двухбайтового символа Unicode. Обычно Unicode-символы кодируются от 1 до 4 байтов. Эмодзи, например, кодируются четырьмя.

🔍 Шаг 2:
Postgres ожидал, что следующий байт тоже будет частью этого Unicode-символа, но вместо него получил байт 0x27, что соответствует обычной одиночной кавычке '.

🔥 Шаг 3:
Ключевой баг был в функции PQescapeStringInternal — она не проверила корректность Unicode-последовательности, а просто взяла и «переписала» кавычку, оставив её без защиты. Это открыло дверь для классической SQL-инъекции.

🛠️ Шаг 4:
Beyond Trust использовали библиотеку libpq и команду psql, что позволило хакерам не только читать данные, но и выполнять любые команды на сервере, включая запуск произвольных программ через \! command.

Вот так, буквально через пару символов, вся система была взломана.

🧐 Почему так долго не замечали уязвимость?

Самое удивительное здесь — долгожительство уязвимости. PostgreSQL — один из самых надёжных open-source проектов, тщательно проверяемый тысячами специалистов и компаний. Как такое могло случиться?

Есть две главные причины:

🎯 Узкая специализация бага.
Эта ошибка была специфичной и могла проявиться только в очень редких сценариях использования PostgreSQL через CLI-интерфейс (psql).

🧩 Слепая вера в старые библиотеки.
Многие разработчики привыкли полагаться на встроенные механизмы экранирования строк. Никто не ожидал, что именно стандартная функция экранирования может стать причиной SQL-инъекции.

🛡️ Уроки и выводы из инцидента

Этот случай напоминает нам несколько важных вещей:

✅ Никогда не доверяй полностью даже проверенному ПО.
Любая библиотека или инструмент могут содержать неизвестные уязвимости, особенно связанные с обработкой строк и Unicode.

✅ Всегда проверяй входные данные на каждом уровне приложения.
Подготовленные запросы (prepared statements) – важнейшая защита от SQL-инъекций. Их следует использовать всегда и везде.

✅ Понимать Unicode важнее, чем кажется.
Сегодня почти любое приложение сталкивается с обработкой многоязычных текстов и эмодзи. Безопасность начинается с глубокого понимания того, как кодируются и обрабатываются строки.

🎭 Личное мнение автора

Инцидент с казначейством США — потрясающий пример того, насколько сложной и запутанной может быть современная кибербезопасность. Казалось бы, банальная SQL-инъекция уже давно изучена и должна была уйти в историю. Но на деле даже лучшие умы индустрии всё ещё допускают критические ошибки, связанные с обработкой простых символов.

Самое интересное, пожалуй, то, что весь этот взлом уместился буквально в двух байтах: чуть больше одного символа. Удивительно и пугающе одновременно.

А ещё удивительнее, что подобные атаки могут скрываться даже в эмодзи. Ведь они тоже Unicode, и, как оказалось, через них можно передавать и более сложные «тайные» данные.

🌟 Интересные факты:

🔹 Эмодзи способны хранить скрытые данные.
Известен случай, когда исследователь Пол Батлер смог «спрятать» произвольные данные прямо внутри эмодзи — это идеальный метод для скрытой передачи информации.

🔸 Любой может «усыновить» эмодзи.
За $5000 можно официально стать «спонсором» символа Unicode. Этим уже воспользовались компании вроде Buffalo Wild Wings (спонсор куриной ножки 🍗) и даже бейсбольная команда Oakland Athletics (усыновили ⚾, 🐘 и 🌳).

📚 Источники и полезные ссылки:

• 🔗 Оригинальная статья Slam Dunk Software
• ⚙️ Git-коммит с исправлением ошибки

Этот случай — напоминание каждому из нас: мир ИТ-безопасности полон сюрпризов, и иногда даже эмодзи могут стать угрозой национальной безопасности! 🌐😅