Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Самоподписанный серт не будет считаться доверенным, ведь не подписан доверенным CA, на то он и самоподписанный
А LetsEncrypt требует подтвердить владение доменом либо через специальный файл, доступный по HTTP, либо через специальную DNS запись (и проверять он ее вряд ли будет через скомпрометированный DNS сервер)
Так что перехватить HTTPS едва ли представляется возможным, хотя иные виды атак все еще имеют место быть (например, можно спокойно перехватить HTTP, пусть его и не так много в современном вебе)
Проблема не столько в том, что автор решил защитить свою программу, сколько в том, как он это делает. Встраивание малвари - явный перебор. Аврот в любой момент может добавить что-то более вредоносное в скачиваемую нагрузку.
«Твой Дневник» каждые 20 минут будет присылать уведомления об оценках. Так как это сервис-посредник, вы понимаете, что по факту, если у нас 200 пользователей, то серверу придётся делать 200 авторизаций/запросов по токену, 200 раз прогружать расписание детей, 200 раз сравнивать, есть ли id полученной оценки в базе данных и 200-old_marks раз отправлять уведомление на устройства.
Почему бы не отправлять уведомление когда оценка будет выставлена? И не придется проверять новые оценки каждые 20 минут.
Вместо использования System.load, который требует полный путь до библиотеки, лучше использовать метод System.loadLibrary, который принимает название библиотеки. Она будет грузиться из java.library.path. (Его можно указать в параметрах JVM через -D)
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
Видны, указатель на функцию можно получить через findExportByName() (как у автора в посте)
Затем можно и вызвать через NativeFunction
Да, неточно выразился, но мысль была такая: ей всё равно
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Верно.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Эта слитая в 2024 году база данных (как минимум, ее часть) была в открытом доступе. Даже новость на хабре была: https://habr.com/ru/news/839076/
Тем не менее, присутствие этой информации для конкретного приложения дает понять, что оно установлено (и автору статьи интересен именно этот факт)
Самоподписанный серт не будет считаться доверенным, ведь не подписан доверенным CA, на то он и самоподписанный
А LetsEncrypt требует подтвердить владение доменом либо через специальный файл, доступный по HTTP, либо через специальную DNS запись (и проверять он ее вряд ли будет через скомпрометированный DNS сервер)
Так что перехватить HTTPS едва ли представляется возможным, хотя иные виды атак все еще имеют место быть (например, можно спокойно перехватить HTTP, пусть его и не так много в современном вебе)
Проблема не столько в том, что автор решил защитить свою программу, сколько в том, как он это делает. Встраивание малвари - явный перебор. Аврот в любой момент может добавить что-то более вредоносное в скачиваемую нагрузку.
Почему бы не отправлять уведомление когда оценка будет выставлена? И не придется проверять новые оценки каждые 20 минут.