Брешь в Apache Struts спустя год все еще используется киберпреступниками

Брешь в Apache Struts спустя год все еще используется киберпреступниками

Брешь в Apache Struts спустя год все еще используется киберпреступниками

Спустя год после того, как исследователи отметили первые попытки эксплуатации критической уязвимости во фреймворке Apache Struts 2, киберпреступники продолжают сканировать Сеть в надежде найти уязвимые серверы.

Уязвимость, о которой идет речь, известна под идентификатором CVE-2017-5638, она затрагивает версии с Struts 2.3.5 по 2.3.31, а также с Struts 2.5 по 2.5.10. Брешь была устранена 6 марта 2017 года с выходом версий 2.3.32 и 2.5.10.1.

Ошибка, вызванная неправильной обработкой заголовка Content-Type, может быть воспроизведена при осуществлении загрузки файлов с помощью парсер Jakarta Multipart. Она позволяет неавторизованному злоумышленнику удаленно выполнить произвольные команды в целевой системе.

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

Гай Бруно, исследователь SANS Internet Storm Center, в минувшие выходные сообщил, что его honeypot-ловушка поймала значительное количество попыток эксплуатации недостатка CVE-2017-5638 в течение последних двух недель.

За одно только воскресение таких попыток насчиталось 57, все они на портах 80, 8080 и 443. Специалист предполагает, что все атаки использовали общедоступный эксплойт, однако Бруно отметил, что ему пока не удалось выявить никакого пейлоада. IP-адреса, с которых происходило сканирование, располагаются в Азии.

«Злоумышленники ищут либо непропатченные серверы, либо новые установки, которые не были защищены должным образом», — отметил Бруно.

Стоит отметить, что именно брешь CVE-2017-5638 была использована в атаке на Бюро кредитных историй США Equifax.

Зачем Яндекс Go создал отдельный язык для расчёта стоимости поездок

Цена поездки в Яндекс Go — это не расстояние, умноженное на минуты и километры. В расчёт вмешиваются геозоны, спрос, скидки, платные дороги, дополнительные остановки и требования вроде перевозки кота, велосипеда или лыж. Чтобы управлять этим хозяйством без бесконечных деплоев, разработчики вынесли алгоритм ценообразования из кода сервиса в собственный язык.

Как объяснили разработчики в статье на Хабре, прайсинг работает не только при заказе машины.

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

 

Сначала сервисы параллельно собирают параметры поездки: тарифную категорию, геозоны, скидки, повышенный спрос и дополнительные услуги. Зависимости между источниками выстраиваются в граф, а запросы выполняются асинхронно на базе userver. Если некритичный источник не ответил, весь расчёт не падает.

 

Сам алгоритм раньше можно было бы держать в C++, но он меняется в среднем дважды в неделю. Выкатка сервиса на 50 подов занимает около 40 минут, а лес динамических конфигов быстро превратил бы код в музей условных операторов.

Поэтому Яндекс разработал собственный DSL. В нём есть условия, функции, неизменяемые значения и fold вместо циклов. Правила собираются в последовательную цепочку: каждое преобразование получает текущую цену и параметры, а возвращает новый результат с метаданными. Грамматику описали через ANTLR 4, а верификатор Z3 проверяет, что программа не выдаст некорректную цену.

 

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

 

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

RSS: Новости на портале Anti-Malware.ru