Спамеры заинтересовались национальными доменными именами

Спамеры заинтересовались национальными доменными именами

...

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



Напомним, что национальные доменные имена (IDN) постепенно вводятся в строй параллельно с традиционными. Эти адреса могут содержать не только привычную латиницу, но и символы кириллического, арабского или китайского алфавита. "Интернационализация" достигла уже и доменов первого уровня, примером чему является новый российский сектор адресов - .РФ.


Теперь же подразделение Symantec MessageLabs предупреждает, что такие имена начинают использовать и спамеры. В частности, аналитики зафиксировали применение IDN-идентификаторов для перевода пользователей на сайты рекламного характера; представитель компании Ник Джонстон привел в качестве примера недавно перехваченные письма, предлагающие немецким пользователям Сети фармпрепараты специфического назначения. В этих почтовых сообщениях содержались ссылки, ведущие на популярный сервис сокращения URL-адресов; оттуда обозреватель жертвы перенаправлялся в кириллический домен, а затем - через секунду - очередное изменение маршрута выводило его на сайт, изображающий "Интернет-магазин швейцарской фармацевтической компании".


Г-н Джонстон отметил, что в такой ситуации заметить в адресной строке браузера IDN-имя довольно проблематично - а, следовательно, в процессе всех вышеописанных перенаправлений получатели нежелательной почты могли и не обратить внимания на необычный домен. По его словам, MessageLabs ожидает роста популярности национальных веб-адресов среди распространителей мусорных писем: во-первых, на данный момент гораздо проще найти свободный идентификатор IDN, чем никем не занятое доменное имя на латинице, а во-вторых, регистраторы сейчас привлекают клиентов сниженными ценами, эконом-пакетами и прочими выгодными предложениями, чтобы повысить количество заказов на подобные домены.


V3.co.uk

ChatGPT и DeepSeek пропускают до 50% уязвимостей в софте на Java и Python

Группа компаний «Солар» проверила, насколько хорошо большие языковые модели справляются с двумя самыми трудоёмкими задачами в безопасной разработке — триажем уязвимостей и их исправлением в коде. Итог исследования получился довольно показательный: популярные общедоступные модели ускоряют работу, но пока слишком часто ошибаются, чтобы полностью на них полагаться.

Эксперты Solar appScreener протестировали шесть LLM на 20 крупных приложениях на Java и Python, каждое объёмом более 100 тысяч строк кода. Для анализа использовали как облачные модели — GigaChat 3 PRO, ChatGPT 5.2 и DeepSeek 3.2, так и локальные решения on-premise, включая ChatGPT OSS, Mistral и специализированные модели DerTriage и DerCodeFix.

Сначала с помощью SAST-анализа в проектах нашли около 12 тысяч уникальных срабатываний, из которых почти 20% пришлись на уязвимости высокой критичности. После этого все модели получили одинаковый промпт с описанием уязвимости, фрагментом кода, трассой достижимости и идентификаторами CWE.

На этапе триажа результаты оказались неровными. В Java-проектах среди облачных моделей лучше всех выступил ChatGPT с точностью 60,9%, а DeepSeek показал лишь 50%. В Python-коде картина поменялась: DeepSeek добрался до 80%+, а ChatGPT показал 52,7%. Но лучший результат среди локальных решений продемонстрировала DerTriage — более 80% точности и для Java, и для Python.

С кодфиксом ситуация похожая. Для Java ChatGPT показал 61,8% точности, DeepSeek — 45,5%. В Python их показатели составили 46,6% и 44,8% соответственно. Локальная модель DerCodeFix снова оказалась впереди: 78,2% точности на Java и 83,1% на Python.

Главный вывод исследования простой: LLM действительно экономят время, но на самых ответственных этапах безопасной разработки универсальные модели пока не дают нужной надёжности. Если команда безоговорочно доверится таким инструментам, есть риск пропустить критичные уязвимости.

В «Соларе» также напоминают ещё об одной проблеме: использование облачных моделей может стать каналом утечки исходного кода. Поэтому для задач безопасной разработки компания рекомендует смотреть в сторону локальных моделей on-premise, которые работают в закрытом контуре и всё равно требуют проверки со стороны AppSec-инженера.

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