Очень буду ждать! Честно говоря, уже устал, что разные OEM производители клали причинное место на фиксы хотя бы критических и мажорных уязвимостей в более-менее новой технике. TP-Link, вам особенный привет
Тут вы хорошо раскрыли темы. Если не ошибаюсь, то в 2020 году только Let's Encrypt начал полностью проверять DNSSEC и там же писали они сами, что некоторые операции не требуют этого делать, однако им был сложно городить логику исключений, да и незачем, поэтому полностью проверяют. А вот остальные УЦ - это большой вопрос. Учитывая их олигапольный статус, вряд ли они каждый день читают всякие RFC и про всякие уязвимости, чтобы обезопасить своих клиентов и себя. Помнится мнения этих ребят смогли изменить совместно только гугл, мозилла и ряд других крупняков.
Если не возражаете, для полноты картины читателям, я бы хотел закрепить ваш комментарий.
Тут я поддерживаю комментаторов - в ACME и так используется ID аккаунта и ключ, который хранится на сервере. Тут, если ломанут сервер, то хотя бы у админа будет шанс об этом узнать через установленные Wazah или OSSEC, либо иные HIDS системы. А когда на твою платформу совершают такую атака, как на джаббер, то тут админ никак не сможет узнать (ну пока не забудут обновить протухший сертификат нападающие).
Интересные времена пошли, что теперь можно снизить credibility комментария натягиванием нейронки.
Я делаю свои выводы на основе двух репортов, которые выше уже мной приведены. И там, как раз, и wine_get_version есть (hybrid analysis) и slui.exe (any.run), вы, наверное, не читали репорты.
если у вас нет экспертизы - зачем вы вообще пытаетесь спорить?
А тут у нас попытка авторитетом задавить?
В общем - я жду Вашего анализа, лично Вашего, не нейронки, хоть сколько-то углубленного, ручного.
А тут попытка покомандовать другим человеком.
В общем, я попытался вам помочь в силу своих возможностей. Дальше уже вам решать, что делать. Я же прекращаю тут писать комментарии.
Да, вы правы, что каждый отдельный индикатор можно интерпретировать как легитимный. Однако задача аналитика и ML сканера - смотреть на всю картину в целом. И вот что выходит:
1. Про упаковщик/протектор, энтропию и анти-отладку.
Использование протектора объясняет и высокую энтропию секций, и наличие анти-отладочных приемов. Но для специалиста по безопасности использование подобных упаковщиков - это само по себе огромный красный флаг. Легитимные разработчики используют их для защиты своего кода, но 99% всей малвари в дикой природе использует их для сокрытия вредоносного функционала. Когда аналитик и/или ML сканнер видит упакованный файл без подписи, он не думает: "О, разработчик защищает свою интеллектуальную собственность". Он думает: "От меня что-то прячут, и я должен выяснить, что именно".
2. Про slui.exe
Я перепроверил граф вызовов в отчете any.run. Да, MetaSkins.exe не вызывает slui.exe напрямую. Его вызывает системный сервис SppExtComObj.Exe. Это моя неточность однако этот вызов произошел во время работы вашего приложения. Это нетипичное совпадение. Почему во время работы обычного лаунчера вдруг активизируется служба защиты ПО Windows? Возможно, ваше приложение делает какой-то специфичный запрос или вызов, который триггерит эту службу. Для меня это остается подозрительным, которое требует объяснения. Само по себе это не доказывает злой умысел, но добавляет веса в общую копилку подозрительной активности.
3. Про C2, домен и .onion строки
"Как вы определили, что сервер является C2?" Когда анализируешь ПО, любой сервер, с которым приложение связывается для получения данных, функционально является C2 сервером для этого приложения. Это его "командный центр". Когда этот сервер прячется за Cloudflare, а само приложение неподписано и использует техники уклонения от анализа, любой эксперт будет рассматривать этот канал связи как потенциально вредоносный C2.
"В чем поинт про .onion?" Да, Вы говорите, что это просто часть библиотеки curl. Но вопрос не в этом. Вопрос: зачем в простом лаунчере для винды библиотека, которая умеет работать с Tor и другая библиотека, которая почему-то работает с wine? Это избыточный функционал, который непонятно почему там присутствует. Даже если вы не используете этот функционал, его наличие в коде - это уже странно.
Даже если принять все ваши объяснения, картина получается следующая:
Мы имеем приложение, которое упаковано коммерческим протектором, скрывающим его истинный код, без цифровой подписи. Это приложение использует анти-отладочные приемы и заснуло 525 раз во время анализа. Во время его работы происходят нетипичные системные вызовы (триггер slui.exe). Оно имеет функционал для доступа к буферу обмена, перехвата клавиатуры и содержит в себе код для работы с анонимной сетью Tor. Его основной домен спрятан за Cloudflare и тоже помечен, как подозрительный или вредоносный. Учитывая перегруженность аналитиков, никто не будет залезать и стараться зареверсить прогу, чтобы понять, что она делает на самом деле.
Да, ни один из этих пунктов в отдельности не является 100% доказательством, но их совокупность создает подозрительное впечатление, а антивирусным компаниям проще заблочить, чем разбираться.
И хотя описанная в статье "force false-positive" - это реальная проблема, конкретно ваш файл сам по себе вызывает слишком много вопросов. Дело не в том, что его кто-то запустил рядом с вирусом. Дело в том, что он сам ведет себя как какой-то троянец.
Вот лишь несколько самых очевидных красных флагов из этих репортов:
Сбор информации о системе и подозрительные вызовы. Чтение BIOS, проверка UAC, и, что самое странное, — запуск slui.exe (клиент активации Windows). У легитимного лаунчера нет причин обращаться к компонентам лицензирования ОС.
Активные попытки уклонения от анализа. Тут целый букет: от прямых вызовов IsDebuggerPresent до использования TLS-коллбэков для выполнения кода до основной точки входа - зачем? Секции с аномально высокой энтропией (.text, .data, .rsrc) - тут использование упаковщика или шифровщика для защиты от реверс-инжиниринга.
Прямые индикаторы шпионского ПО. Отчет Hybrid-Analysis четко указывает на наличие функционала для перехвата клавиатуры ("retrieve keyboard strokes") и доступа к буферу обмена ("open the clipboard"). Это уже не просто подозрительно, а гиперподозрительно!
Сетевая активность и C2. Связь идет с C2-сервером (api.metaskins.gg), который помечен вредоносным. Вдобавок, в теле файла найдены строки с .onion - ну тут сами думайте.
Так что дело не в "соседстве с вредоносом в цепочке процессов". Ваш файл, судя по всему, и сам использует сомнительные техники + ещё и не подписан.
Вроде бы приватный ключ зашифрован паролем и тогда так хранится. Это, конечно, не 100% гарантия безопасности, потому что можно стартануть перебор паролей, перехватив его, но и не 100% небезопасность. Только если пароль не передаёте по тому же каналу либо иному незащищённому.
А так, можно и стулом порезаться, и бумагой убиться, если желание будет.
Упомянули структурные данные. Я потестил несколько AI (включая Perplexity, Grok-3, ChatGPT, Gemini), задавав вопросы, ответы на которые можно найти исключительно в JSON-LD страницы, однако они просто этот код не видели. Вывод в том, что эти боты пока не умеют читать структурные данные. Я вообще не думаю, что они читают код страницы.
Как и запутанные и разношёрстные правила. Например, существует проект Wikidata - русскоязычная википедия неплохо использует эти данные для показа виджета слева по шаблонам, однако англоязычная википедия не так хорошо интегрирована с Wikidata. Поэтому приходится вручную копировать данные, что тупо. Брать источники с Wikidata тоже целый квест, чтобы использовать в Вики.
Далее, крайне сложно вкатываться в шаблоны, потому что они раскиданы в не интуитивных местах - приходиться тратить уйму времени, чтобы найти тот самый.
Далее, вписывание метаданных источников - трудоёмкий процесс, особенно когда источников 30+. Тут бы хорошо помог ИИ, но сообщество редакторов относится нейтрально-негативно - продвинутые ребята уже с закрытыми глазами привыкли всё делать.
Я, например, в JSON храню вообще всю информацию о себе (нужно для ََAI) и файл занимает 200 кб. Думаю уже это из JSON превратить в энбеддинги и зафигачить в Graph RAG.
Дальше, для резюме ещё треба оптимизировать по ключевикам. Нормальное решение я не нашёл, писать код такой сложности не умею (я продакт), поэтому делаю всё с ИИ - родилось вот такое: https://github.com/DavidOsipov/Keywords4CV
С DANE вообще всё плохо у почтовиков - его почти нету. А если есть, то он настроен на сервере отдавать отпечатки сертификатов, но сам сервер не проверяет отпечатки других серверов. Вот проверьте своего почтовика https://havedane.net/
Вопрос не только в "поганых кодировщиках" прошлого, но и в принципиальных различиях в работе психоакустических моделей MP3 и Opus. Насколько "интеллектуальнее" Opus справляется с уже "упрощенным" MP3 потоком? Не усиливает ли повторное квантование артефакты, внесенные MP3? Но это только из того, что знаю и слышал - глубоко не копал на практике.
Очень буду ждать! Честно говоря, уже устал, что разные OEM производители клали причинное место на фиксы хотя бы критических и мажорных уязвимостей в более-менее новой технике. TP-Link, вам особенный привет
Тут вы хорошо раскрыли темы. Если не ошибаюсь, то в 2020 году только Let's Encrypt начал полностью проверять DNSSEC и там же писали они сами, что некоторые операции не требуют этого делать, однако им был сложно городить логику исключений, да и незачем, поэтому полностью проверяют. А вот остальные УЦ - это большой вопрос. Учитывая их олигапольный статус, вряд ли они каждый день читают всякие RFC и про всякие уязвимости, чтобы обезопасить своих клиентов и себя. Помнится мнения этих ребят смогли изменить совместно только гугл, мозилла и ряд других крупняков.
Если не возражаете, для полноты картины читателям, я бы хотел закрепить ваш комментарий.
Кстати, об этом уже давно ходят слухи, что там что-то в этом плане может быть зарыто. Об этом писал Хьюго Ландау.
Тут я поддерживаю комментаторов - в ACME и так используется ID аккаунта и ключ, который хранится на сервере. Тут, если ломанут сервер, то хотя бы у админа будет шанс об этом узнать через установленные Wazah или OSSEC, либо иные HIDS системы. А когда на твою платформу совершают такую атака, как на джаббер, то тут админ никак не сможет узнать (ну пока не забудут обновить протухший сертификат нападающие).
Статья отличная, а ситуация патовая. Как раз у самого такой же ноут и один Мао знает когда китайцы выпустят OEM патч. Тем не менее, плюсик в карму.
И ограничить власть Линуса самого, чтобы просто так не прощался с разрабами по своей прихоти или по прихоти своих спонсоров.
Интересные времена пошли, что теперь можно снизить credibility комментария натягиванием нейронки.
Я делаю свои выводы на основе двух репортов, которые выше уже мной приведены. И там, как раз, и wine_get_version есть (hybrid analysis) и slui.exe (any.run), вы, наверное, не читали репорты.
А тут у нас попытка авторитетом задавить?
А тут попытка покомандовать другим человеком.
В общем, я попытался вам помочь в силу своих возможностей. Дальше уже вам решать, что делать. Я же прекращаю тут писать комментарии.
Да, вы правы, что каждый отдельный индикатор можно интерпретировать как легитимный. Однако задача аналитика и ML сканера - смотреть на всю картину в целом. И вот что выходит:
1. Про упаковщик/протектор, энтропию и анти-отладку.
Использование протектора объясняет и высокую энтропию секций, и наличие анти-отладочных приемов. Но для специалиста по безопасности использование подобных упаковщиков - это само по себе огромный красный флаг. Легитимные разработчики используют их для защиты своего кода, но 99% всей малвари в дикой природе использует их для сокрытия вредоносного функционала. Когда аналитик и/или ML сканнер видит упакованный файл без подписи, он не думает: "О, разработчик защищает свою интеллектуальную собственность". Он думает: "От меня что-то прячут, и я должен выяснить, что именно".
2. Про slui.exe
Я перепроверил граф вызовов в отчете any.run. Да, MetaSkins.exe не вызывает slui.exe напрямую. Его вызывает системный сервис SppExtComObj.Exe. Это моя неточность однако этот вызов произошел во время работы вашего приложения. Это нетипичное совпадение. Почему во время работы обычного лаунчера вдруг активизируется служба защиты ПО Windows? Возможно, ваше приложение делает какой-то специфичный запрос или вызов, который триггерит эту службу. Для меня это остается подозрительным, которое требует объяснения. Само по себе это не доказывает злой умысел, но добавляет веса в общую копилку подозрительной активности.
3. Про C2, домен и .onion строки
"Как вы определили, что сервер является C2?" Когда анализируешь ПО, любой сервер, с которым приложение связывается для получения данных, функционально является C2 сервером для этого приложения. Это его "командный центр". Когда этот сервер прячется за Cloudflare, а само приложение неподписано и использует техники уклонения от анализа, любой эксперт будет рассматривать этот канал связи как потенциально вредоносный C2.
"В чем поинт про .onion?" Да, Вы говорите, что это просто часть библиотеки curl. Но вопрос не в этом. Вопрос: зачем в простом лаунчере для винды библиотека, которая умеет работать с Tor и другая библиотека, которая почему-то работает с wine? Это избыточный функционал, который непонятно почему там присутствует. Даже если вы не используете этот функционал, его наличие в коде - это уже странно.
Даже если принять все ваши объяснения, картина получается следующая:
Мы имеем приложение, которое упаковано коммерческим протектором, скрывающим его истинный код, без цифровой подписи. Это приложение использует анти-отладочные приемы и заснуло 525 раз во время анализа. Во время его работы происходят нетипичные системные вызовы (триггер slui.exe). Оно имеет функционал для доступа к буферу обмена, перехвата клавиатуры и содержит в себе код для работы с анонимной сетью Tor. Его основной домен спрятан за Cloudflare и тоже помечен, как подозрительный или вредоносный. Учитывая перегруженность аналитиков, никто не будет залезать и стараться зареверсить прогу, чтобы понять, что она делает на самом деле.
Да, ни один из этих пунктов в отдельности не является 100% доказательством, но их совокупность создает подозрительное впечатление, а антивирусным компаниям проще заблочить, чем разбираться.
Имхо, прочитав репорты о вашем exeшнике, я бы сам его пометил малварью
Репорт Hybrid-analysis
Репорт any.run
И хотя описанная в статье "force false-positive" - это реальная проблема, конкретно ваш файл сам по себе вызывает слишком много вопросов. Дело не в том, что его кто-то запустил рядом с вирусом. Дело в том, что он сам ведет себя как какой-то троянец.
Вот лишь несколько самых очевидных красных флагов из этих репортов:
Сбор информации о системе и подозрительные вызовы. Чтение BIOS, проверка UAC, и, что самое странное, — запуск slui.exe (клиент активации Windows). У легитимного лаунчера нет причин обращаться к компонентам лицензирования ОС.
Активные попытки уклонения от анализа. Тут целый букет: от прямых вызовов IsDebuggerPresent до использования TLS-коллбэков для выполнения кода до основной точки входа - зачем? Секции с аномально высокой энтропией (.text, .data, .rsrc) - тут использование упаковщика или шифровщика для защиты от реверс-инжиниринга.
Прямые индикаторы шпионского ПО. Отчет Hybrid-Analysis четко указывает на наличие функционала для перехвата клавиатуры ("retrieve keyboard strokes") и доступа к буферу обмена ("open the clipboard"). Это уже не просто подозрительно, а гиперподозрительно!
Сетевая активность и C2. Связь идет с C2-сервером (api.metaskins.gg), который помечен вредоносным. Вдобавок, в теле файла найдены строки с .onion - ну тут сами думайте.
Так что дело не в "соседстве с вредоносом в цепочке процессов". Ваш файл, судя по всему, и сам использует сомнительные техники + ещё и не подписан.
Вроде бы приватный ключ зашифрован паролем и тогда так хранится. Это, конечно, не 100% гарантия безопасности, потому что можно стартануть перебор паролей, перехватив его, но и не 100% небезопасность. Только если пароль не передаёте по тому же каналу либо иному незащищённому.
А так, можно и стулом порезаться, и бумагой убиться, если желание будет.
Упомянули структурные данные. Я потестил несколько AI (включая Perplexity, Grok-3, ChatGPT, Gemini), задавав вопросы, ответы на которые можно найти исключительно в JSON-LD страницы, однако они просто этот код не видели. Вывод в том, что эти боты пока не умеют читать структурные данные. Я вообще не думаю, что они читают код страницы.
Вот с этим у меня проблемы - предпочитаю логичные и чёткие правила, чем опираться на чувства свои и n-ного кол-ва народу.
Годно, привет от другого B2B продакта. Ток дайте ИИ вычитать перед публикацией.
Каждый факт должен быть подкреплён источниками в вики. Даже если ИИ сгалюцинировал, то это легко проверить, тыкнув на источник.
Как и запутанные и разношёрстные правила. Например, существует проект Wikidata - русскоязычная википедия неплохо использует эти данные для показа виджета слева по шаблонам, однако англоязычная википедия не так хорошо интегрирована с Wikidata. Поэтому приходится вручную копировать данные, что тупо. Брать источники с Wikidata тоже целый квест, чтобы использовать в Вики.
Далее, крайне сложно вкатываться в шаблоны, потому что они раскиданы в не интуитивных местах - приходиться тратить уйму времени, чтобы найти тот самый.
Далее, вписывание метаданных источников - трудоёмкий процесс, особенно когда источников 30+. Тут бы хорошо помог ИИ, но сообщество редакторов относится нейтрально-негативно - продвинутые ребята уже с закрытыми глазами привыкли всё делать.
Я уже было успел взорваться праведным гневом, что даже мой комп имеет 16 гигов, а тут какой-то телефончик
Ну, человек решил свою проблему.
Я, например, в JSON храню вообще всю информацию о себе (нужно для ََAI) и файл занимает 200 кб. Думаю уже это из JSON превратить в энбеддинги и зафигачить в Graph RAG.
Дальше, для резюме ещё треба оптимизировать по ключевикам. Нормальное решение я не нашёл, писать код такой сложности не умею (я продакт), поэтому делаю всё с ИИ - родилось вот такое: https://github.com/DavidOsipov/Keywords4CV
Каждый решает свои проблемы так, как умеет :)
С DANE вообще всё плохо у почтовиков - его почти нету. А если есть, то он настроен на сервере отдавать отпечатки сертификатов, но сам сервер не проверяет отпечатки других серверов. Вот проверьте своего почтовика https://havedane.net/
У почтовиков ещё отдельная песня - правильная имплементация SPF, DKIM, DMARC, MTA-STS. Зачастую там полный беспорядок.
Вопрос не только в "поганых кодировщиках" прошлого, но и в принципиальных различиях в работе психоакустических моделей MP3 и Opus. Насколько "интеллектуальнее" Opus справляется с уже "упрощенным" MP3 потоком? Не усиливает ли повторное квантование артефакты, внесенные MP3? Но это только из того, что знаю и слышал - глубоко не копал на практике.