Главное Свежее Вакансии Образование
Комментируемое:
😼
Выбор
редакции
774 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Безопасность программного обеспечения с открытым исходным кодом

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

Только половина компаний применяют политики безопасности программного обеспечения с открытым исходным кодом. Об этом говорит Robert Lemos в журнале Data Center Knowledge.

Программное обеспечение с открытым исходным кодом (open source software — OSS) имеет значительные преимущества в разработке приложений, но компании также должны быть готовы и к недостаткам. Согласно одному из отчетов, приложение JavaScript имеет наибольшее количество зависимостей — в среднем 174 на проект, что примерно в семь раз больше, чем язык с наименьшим количеством зависимостей, Python — 25 на проект.

Данные также показывают, что разные языки, как правило, имеют разную серьезность недостатков. Средний проект, написанный на Java, например, имел более 47 уязвимостей высокой степени серьезности и 28 уязвимостей средней степени серьезности, что намного выше, чем у проектов на JavaScript, которые имели в среднем 18 и 21 уязвимость соответственно. Однако у Python было больше всего уязвимостей с низкой степенью опасности, в среднем 20 на проект.

На количество и типы уязвимостей влияет множество факторов — сложность проектов, количество разработчиков и популярность. Наиболее популярные проекты, скорее всего имеют и больше всего ошибок.

Что касается исправления ошибок, то приложения, написанные на .NET, например, имели самое большое среднее время — 148 дней, за ними следует JavaScript. Между тем приложения, написанные на Go, имели самое быстрое время для исправления и обычно исправлялись за треть этого времени — за 49 дней.

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

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

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

===

Немного фактографии


Приводим несколько новостей из различных ниш свободно распространяемого ПО:

1. Специалисты безопасности цепочек поставок ПО Sonatype обнаружили очередные вредоносные пакеты Python PyPi, посредством которых подтягивалась конфиденциальная информация, включая учетные данные AWS. Среди них: loglib-modules, pyg-modules, pygrata, pygrata-utils и hkg-sol-utils. При этом первые два пакета закамуфлированы под известные проекты на PyPI, вводя в заблуждение невнимательных или неопытных разработчиков в ходе их имплементации, последние три не имеют явного таргетинга, но все имеют сходство кода или взаимосвязи.

Перехватываемые данные хранились в формате TXT и передавались через домен PyGrata[.]com. При этом конечная точка не была защищена должным образом, в связи с чем аналитики могли ознакомиться со всем, что утекло.

2. Тайваньский производитель QNAP, похоже что, нашел причину новых атак на владельцев своих сетевых хранилищ (NAS). Разработчики сейчас находятся в стадии активного исправления критической уязвимости PHP трехлетней давности, которая приводит к RCE. Уязвимость затрагивает версии PHP 7.1.x ниже 7.1.33, 7.2.x ниже 7.2.24 и 7.3.x ниже 7.3.11 с кривой конфигурацией nginx (с конфигурациями, отличными от настроек по умолчанию). Она отслеживается как CVE-2019-11043 и имеет рейтинг серьезности 9,8 из 10 в системе оценки CVSS.

Однако пока производитель пытается бороться с DeadBolt, владельцев NAS с выходных начали атаковать вымогатели ech0raix, согласно отчетам пользователей и образцам, представленным на платформе ID Ransomware. При этом вектор заражения, используемый в новых кампаниях DeadBolt и ech0raix, остается неизвестным. До момента выяснения всех обстоятельств QNAP рекомендует клиентам перейти на новейшую версию операционных систем QTS или QuTS hero, а также отключить устройства от интернета. Если устройства имеют такие подключения, то пользователям следует отключить функцию переадресации портов маршрутизатора и UPnP QNAP NAS.

3. Разработчики WordPress обратились к принудительному обновлению в рамках противодействия масштабной кампании, нацеленной на уязвимые версии плагина Ninja Forms, который используют ежедневно более 1 млн пользователей платформы. Такое решение было принято после обнаружения исследователями Wordfence критической уязвимости RCE в дикой природе. Уязвимость затрагивает несколько выпусков популярного плагина для создания форм, начиная с версии 3.0 и выше.

Злоумышленники, не прошедшие проверку подлинности, могут удаленно использовать ошибку для вызова различных классов форм Ninja в функции слияния тегов, что позволяет им полностью захватить неисправленные сайты WordPress с помощью нескольких цепочек эксплуатации, одна из которых приводит к удаленному выполнению кода посредством десериализации для захвата целевого веб-сайта.

С момента исправления уязвимости 14 июня без официального уведомления более 730 тысяч сайтов WordPress были принудительно обновлены ввиду ошибки плагина. Подробности атак не разглашаются, однако следует все же рассматривать новую RCE серьезной угрозой и если плагин еще не был автоматически обновлен до версии 3.6.11, то это необходимо сделать вручную.

===

Комментарий дата-центра ITSOFT


Мы, безусловно, рекомендуем нашим клиентам соблюдать хотя бы самые минимальные политики безопасности. Например, нужно следить за публикациями на специализированных ресурсах, таких как cve.org и не только, постоянно проверять систему и код на наличие уязвимостей, используя сканеры OpenVAS, Nmap и другие, своевременно обновлять программное обеспечение. Если самостоятельно выполнять комплекс проверок затруднительно, то можно заказать аудит безопасности на стороне или у хостинг-провайдера.

Мы и сами активно используем OSS-продукты под различными лицензиями. Например, на веб-серверах применяем LAMP-стек, nginx, защиту от атак fail2ban. Собственные разработки выполняем также на основе свободного ПО (VS Code, PHP, JS, фреймворки Vue, Nest, и т.д., поэтому резюмируя вышесказанное делаем банальный вывод: используйте Open Source (особенно в свете нынешних подвижек на российском рынке), но не пускайте дело на самотек — следите за политиками безопасности, поскольку без свободно распространяемого ПО уже невозможно представить себе работу интернета.

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.