Взлом MOVEit показывает, что SQL-инъекции по-прежнему являются нашей ахиллесовой пятой

Mar 24, 2024

В конце 1998 года, когда я только начинал свою карьеру в сфере технологий, я прочитал в почтенном журнале Phrack, как плохая очистка входных данных позволила Rain.forest.puppy (псевдоним, использованный Джеффом Форристалом) передавать строки SQL-запроса непосредственно на серверную часть. база данных веб-приложения.

К сожалению, четверть века спустя SQL-инъекция — один из самых низких показателей безопасности — по-прежнему включена в список 10 наиболее уязвимых мест безопасности по версии Open Worldwide Application Security Project (OWASP). Одна из самых страшных атак за всю историю произошла еще в 2008 году, когда была взломана система Heartland Payment Systems и скомпрометированы номера более 130 миллионов кредитных и дебетовых карт. В 2023 году группа вымогателей Cl0p воспользовалась ранее неизвестными уязвимостями SQL-инъекций в MOVEit, программе передачи файлов Progress Software, и скомпрометировала сотни жертв в рамках атаки на цепочку поставок.

У нас нет информации о жизненном цикле разработки программного обеспечения Progress Software или методах обеспечения безопасности, чтобы выяснить, что произошло. Хотя система оценки уязвимостей или даже программа поиска ошибок потенциально могли бы выявить недостатки SQL-инъекций в коде до того, как они будут использованы, сосредоточение внимания на создании кода, который является безопасным по своей конструкции, является еще лучшим способом устранения этого класса уязвимостей.

Методы включают использование хранимых процедур вместо прямой передачи SQL-запросов и использование программных библиотек для очистки входных данных. Это гарантирует, что создаваемый код безопасен по своей конструкции и не требует от команд последующего контроля качества или поиска ошибок, что может быть дорогостоящим и подвержено ошибкам.

Ключевым моментом здесь действительно является принцип «безопасность по конструкции», а это требует образования — как для разработчиков, так и для групп безопасности. Мы часто говорим о «сдвиге влево», и самый крайний сдвиг влево — это образование (например, курсы по основам безопасной разработки программного обеспечения OpenSSF). Если бы разработчики использовали хранимые процедуры и последовательную очистку входных данных по всей базе кода, MOVEit мог бы структурно избежать этого эксплойта. Безопасность должна быть встроена в жизненный цикл разработки программного обеспечения (SDLC) как неотъемлемая часть качества кода, а не просто как контрольная точка или шлюз SDLC перед выпуском.

Точное выявление дефектов безопасности на ранней стадии позволяет разработчикам устранять их системно. В производственной среде обеспечение хороших эксплуатационных практик, таких как непрерывное обновление инфраструктуры в виде кода, выполнение с минимальными привилегиями, изолированная программная среда и изоляция домена, может помочь гарантировать, что группы угроз не получат постоянный доступ к эксплуатируемым сервисам.

Большинство разработчиков знают, что делать, но ставят скорость выше безопасности. Таким образом, образование должно учитывать ценность методов безопасного кодирования и экспоненциальные издержки игнорирования этих методов. Однако такое обучение будет эффективным только в том случае, если разработчики будут чувствовать поддержку, уделяя время, необходимое для безопасного кодирования. Если разработчикам говорят писать код безопасно, но организационная культура явно или неявно наказывает их за «медленность», они наверняка вернутся к небезопасным путям.

Образование не идет только в одном направлении. Команды безопасности, предоставляющие разработчикам информацию об уязвимостях без особого контекста, усложняют ситуацию. Эта информация, часто предоставляемая в виде отчета, который необходимо исправить на контрольной точке на поздней стадии жизненного цикла разработки программного обеспечения, снижает скорость разработки, поскольку они отделяют достоверные результаты от ложных срабатываний. Обучение специалистов по безопасности тому, как стать лучшими инженерами-программистами, может помочь сократить объем работы, связанной с составлением бездействующих отчетов о безопасности, и помочь инженерам-программистам создавать более качественный код.

Уязвимость MOVEit показывает, насколько важно для каждой организации понимать цепочку поставок программного обеспечения. Точная инвентаризация активов программного обеспечения и инфраструктуры является необходимым условием для того, чтобы компании могли реагировать на события кибербезопасности до того, как они станут нарушениями; вот почему существует OpenSSF SBOM Everywhere SIG.

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