Маленькая команда из 40 человек – при этом разработкой клиентов под каждую платформу занимается один, в лучшем случае два человека, которые не успевает исправлять все баги (некоторые не исправляются годами). Какой-то сомнительный повод для гордости получается...
Да и безопасность с шифрованием на уровне "да, мы храним все ваши сообщения, но никто не может их прочитать, честно-честно" тоже такое себе)
Уязвимость, о которой вы вспомнили – CVE-2020-36603 (если кому интересно поискать подробности). Но вообще проблемы с небезопасными драйверами уровня ядра есть не только у античитов игр, но даже у некоторых устройств…
Поэтому всякие важные-секретные ключи лучше хранить отдельно физически.
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же 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 минут.
Маленькая команда из 40 человек – при этом разработкой клиентов под каждую платформу занимается один, в лучшем случае два человека, которые не успевает исправлять все баги (некоторые не исправляются годами). Какой-то сомнительный повод для гордости получается...
Да и безопасность с шифрованием на уровне "да, мы храним все ваши сообщения, но никто не может их прочитать, честно-честно" тоже такое себе)
Уязвимость, о которой вы вспомнили – CVE-2020-36603 (если кому интересно поискать подробности). Но вообще проблемы с небезопасными драйверами уровня ядра есть не только у античитов игр, но даже у некоторых устройств…
Поэтому всякие важные-секретные ключи лучше хранить отдельно физически.
Мне кажется, это достаточно хороший вопрос, можно ли это назвать уязвимостью. Если можно – то в чем заключается ущерб от неё?
Если говорить о том, что приложение благодаря таким "трюкам" может запросто выполнять какой-нибудь небезопасный код, полученный извне, то это будет возможно всегда. Чтобы такое ограничить, это нужно либо mmap над исполняемыми страницами ограничивать (что сломает очень много чего, в том числе JIT), либо политику агрессивного код-сигнинга вводить (как сделали Apple). А вот меры уровня "давайте запретим файлы выполнять" в целом не решают данный вопрос.
А вот какой вопрос они решают – так это, вероятнее всего, чтобы в уже существующих уязвимых приложениях снизить вероятность успешной атаки (первое что приходит в голову: приложение запускает процесс с потенциально "небезопасным" pathname и с ограничениями будет сложнее заменить его на что-то полезное для атакующего)
Уже не в первый раз натыкаюсь на подобные статьи на хабре, и даже не могу отрицать, что тема с анализом MAX довольно актуальная, нооо...
Где же настоящий анализ? Не "давайте посмотрим манифест", "ой я посмотрел и увидел много разрешений" или "джява-классы обфусцированы какой ужас", а уже настоящий разбор того, что этот мессенжер делает: как и когда взаимодействует с сервером и какие данные передает (хотя бы общее представление), для каких конкретных сценариев запрашиваются сомнительные разрешения (та же разблокировка экрана) и другие факты, по которым можно справедливее оценить степень доверия к этому приложению.
А то сейчас от таких разборов складывается лишь разочарование (не в обиду автору)
А в чем этот контроль проявляется для разработчиков (да и пользователей) macOS? Нет, ну вот правда интересно, как человеку, который с ней работает постоянно.
Видны, указатель на функцию можно получить через findExportByName() (как у автора в посте)
Затем можно и вызвать через NativeFunction
Да, неточно выразился, но мысль была такая: ей всё равно
В телеграме огромное количество пользователей, которые пришли в него за контентом и ради любимых каналов и блоггеров. Телеграм стал для многих новой социальной сетью, заменой ВКонтакте, и, к сожалению, такая аудитория не заинтересована в том, с кем Дуров сотрудничает и насколько это для них безопасно...
(говорю не про всех, конечно, это скорее актуально для молодого поколения, частью которого я сам являюсь)
Да, то, что проблема вызвана ТСПУ и действиями РКН не вызывает вопросов. Мы даже не в первый раз с таким сталкиваемся, но сейчас наиболее сильная волна таких «случайных» блокировок.
Самое печальное здесь то, что владельцы попавших под раздачу сервисов ничего не могут с этим поделать(
Это скорее просто интересное совпадение.
Владею проектом, большая часть инфраструктуры которого расположена на OVH. Начиная с 9 июня произошла значительная деградация подключений из РФ: после N килобайт данных соединения просто начинают терять пакеты. Причем это не полный дроп, изредка что-то таки долетает, из-за чего TCP подключения «зависают» в вечных retransmission, и даже определить достоверно, что подключение было «заблокировано» довольно тяжело.
Аналогичные вещи были замечены и с подключениями к другим хостинг-провайдерам. Кто-то жаловался на подключения к CloudFront, кто-то на CloudFlare.
А указанный вами сбой произошел позже, и не затронул, например, OVH. А вот проблемы были. И почему-то только лишь у российских пользователей.
Верно.
Есть ли какие-то подтверждения этим словам? Это довольно сильное заявление, учитывая, что тот же Whats App обещает E2E и различные атаки на него не обходятся одним лишь перехватом трафика
У нашей школы несколько лет назад была вообще странная ситуация: журнал и некоторые сопутствующие сервисы (moodle) хостились прямо в школе, а вход на них был по просто IP адресу, без домена
Однажды со скуки в классе восьмом я обнаружил, что на этом IP адресе еще есть и FTP без авторизации. А там, помимо тонны всяких разных файлов, прямо в корне лежал файл с незашифрованным бэкапом всего школьного журнала. К счастью, именно персональных данных там почти не было (их можно было указать в учетке, но этого не делали ни школьники, ни учителя), зато были пароли надежно (нет) защищенные MD5 без соли
Я не стал об этом никому говорить тогда (остерегаясь последствий), поэтому этот архив пролежал там еще год, пока в новом учебном году школа не решила перейти на другой журнал (и заодно подчистить тот FTP-сервер)
В общем, это я к тому, что в целом в этой "индустрии" все довольно печально и проблемы далеко не единичны
Эта слитая в 2024 году база данных (как минимум, ее часть) была в открытом доступе. Даже новость на хабре была: https://habr.com/ru/news/839076/
Тем не менее, присутствие этой информации для конкретного приложения дает понять, что оно установлено (и автору статьи интересен именно этот факт)
Самоподписанный серт не будет считаться доверенным, ведь не подписан доверенным CA, на то он и самоподписанный
А LetsEncrypt требует подтвердить владение доменом либо через специальный файл, доступный по HTTP, либо через специальную DNS запись (и проверять он ее вряд ли будет через скомпрометированный DNS сервер)
Так что перехватить HTTPS едва ли представляется возможным, хотя иные виды атак все еще имеют место быть (например, можно спокойно перехватить HTTP, пусть его и не так много в современном вебе)
Почему бы не отправлять уведомление когда оценка будет выставлена? И не придется проверять новые оценки каждые 20 минут.