В опубликованном репозитории есть немного интересного кода.
Файл app/src/main/java/e/a/a/j/a/IAuthRepository.java:
public final class IAuthRepository implements IAuthRepository0 {
// ...
public static final class b<T, R> implements Function<T, SingleSource<? extends R>> {
public final /* synthetic */ IAuthRepository a;
public final /* synthetic */ String b;
public final /* synthetic */ String c;
public b(IAuthRepository iAuthRepository, String str, String str2) {
this.a = iAuthRepository;
this.b = str;
this.c = str2;
}
public Object a(Object obj) {
SignResponse signResponse = (SignResponse) obj;
if (signResponse != null) {
return this.a.b.a(
Collections.a(
new Tuples("scope", "http://esia.gosuslugi.ru/usr_inf?mode=w"),
new Tuples("client_id", "PGU"),
new Tuples("grant_type", "password"),
new Tuples("state", signResponse.getStateMarker()),
new Tuples("client_secret", signResponse.getSecret()),
new Tuples("timestamp", signResponse.getTime()),
new Tuples("token_type", "Bearer"),
new Tuples("instanceId", this.a.c.c()),
new Tuples("terminal_name", Build.MODEL),
new Tuples("terminal_type", "Android"),
new Tuples("username", this.b),
new Tuples("password", this.c)
)
);
}
Intrinsics.a("it");
throw null;
}
}
// ...
}
Глубоко не копал, может, URL «esia.gosuslugi.ru/usr_inf?mode=w» не приводит к HTTP-запросу, а используется только как XML Namespace или что-то похожее.
Вопрос знатокам: это намеренная обфускация кода разработчиками или побочный эффект от компиляции? Насколько я вижу, только часть пакетов/классов/методов имеют имена a, b, c, ..., а часть пакетов/классов/методов сумели их сохранить.
А давно это поменяли? В документации про SIGSEGV написано, но про остальное — нет. Вообще, дамп вызывается через SIGQUIT, SIGILL, SIGABRT, SIGFPE и SIGSEGV.
SIGABRT можно перепутать с abort (любой из библиотеки или неотловленное исключение), SIGILL, SIGFPE и SIGSEGV можно перепутать с ошибкой на C/C++ (). SIGQUIT почти никем в дикой природе не используется, а сделать Quit from keyboard для сервиса (демона) — надо постараться.
Под «можно перепутать» имеется в виду интерпретация стандартного админа, который будет расследовать проблему «упал рабочий процесс».
Прочитал, как все здорово и прослезился.
На одном из скриншотов есть галочка «Принудительно завершать проблемные процессы». Думаю, местные специалисты и администраторы оценят юмор разработчиков платформы, которые «завершают проблемные процессы» под Linux путем отправки им сигнала SIGSEGV.
Хорошо. Собственно, даже если создателя [как-то найти и] посадить, сайт + DNS-записи останутся и цель все равно будет достигнута. Провайдер уберет эту систему или пользователи переберутся к провайдерам без таких особенностей.
Другой вариант — сдастся РКН и уберет сайт из реестра сам. Маловероятно.
> Хотите хороших законов — протащите в думу добросовестный и грамотных людей.
> Иначе — сидите под этими и не жалуйтесь.
Еще ближе к реальности следующее: у меня нет знакомых, которые хотят в течение хотя бы года попасть в Думу и бороться с глупостями в режиме один против ста.
А мой домашний провайдер заблокировал доступ к aps.org (American Physical Society). А рабочий — к cloudfront, которым пользуется aps.org. И как жить работать в течение хотя бы года с тем, что есть?
Уголовка за что? За размещение «запрещенной» информации в сети? Или за действия, которые приведут к частичному DoS, в результате чего пострадают пользователи, провайдеры и, частично, ресурсы?
По первому пункту — закон предусматривает только блокировки. Это не очень похоже на уголовку.
По второму пункту — это дыра ошибка в конкретном коммерческом ПО. Я не помню ни одного закона, по которому лицам запрещается вносить DNS-записи для своих доменов. Отмечу, что указанные действия не предполагают несанкционированного вмешательства в чьи-либо сети или системы.
PS: У меня есть публичный (доступный из сети Интернет) сервер, на котором корневая зона "." подписана другим (не официальным) ключом DNSSEC. Меня стоит оштрафовать, посадить или расстрелять?
Или альтернатива: делаем сайт с явными нарушениями, ждем попадания в список, после чего вносим адреса топ-100 популярных у простого населения ресурсов в свои A-записи. Есть подозрение, что такую самодеятельность (разрешение имен) через некоторое время провайдеры выключат. Правда, это нервов попортит простому народу, но…
Не совсем. Любой ключ, как локальный, так и в облаке может быть потерян/похищен/уничтожен. И для предотвращения этого и облако и пользователь могут применять средства обеспечения физической безопасности, резервные копии и т.п. И при этом все равно тяжело защититься от падения метеорита на дом/офис/ДЦ.
Вопрос состоит в другом.
Типичнуя модель угроз строят, исходя из предположения, что злоумышленник знает все, кроме секрета (ключа).
Передавая ключ в облако, мы автоматически расширяем attack surface.
Более того, рассмотрим просто облако.
Пусть облако шифрует ключи, поэтому дамп БД с ключами бесполезен. Пароли от ключей знает только пользователь, поэтому дамп всех данных со всего облака тоже бесполезен. Тогда возникают вопрос: где происходит процесс расшифровки ключа?
1. В облаке? Злоумышленник может перехватить ключ именно в этот момент. Пользователь не заметит.
2. В браузере пользователя? Тогда можно внедрить код на страницу или в скрипты. Или в Я.метрику. Пользователь не заметит. И у пользователя нет возможности проконтроллировать.
3. В клиентском ПО не для браузера? Кто и как гарантирует, что это ПО не сохранит расшифрованный ключ во временную папку?
4. Используется HSM? Кто докажет, что он не выдаст все ключи по недокументированной команде?
Каждый раз, когда говорят «разместим закрытые криптографические ключи в облаке, это так здорово/удобно/современно» возникает вопрос: какие гарантии того, что этот ключ не попадет в третьи руки? И что будет, если-таки попадет?
Когда закрытый ключ лежит на диске/флешке/ключе, то этот вопрос остается целиком и полностью под контролем пользователя.
Все это хорошо до тех пор, пока не появляются интересные факты:
2. Корректные записи DNS. Злоумышленнику это сделать не сложно. Мы прямо сейчас получаем огромное количество спама от разных доменов .eu, причем все домены имеют совершенно корректно настроенный Postfix (не является open relay), совершенно корректные записи DNS (и MX и PTR) и не имеют сайта. Как бороться — непонятно. Пока помогает лишь массовая блокировка по подсетям датацентров с рассадниками.
4. SPF работает неплохо до тех пор, пока ключевой партнер (фирма в 100-1000 раз большая по размеру) не делает кривые настройки у себя, а потом присылает письмо «У вас слишком суровые правила фильтрации, отключите их».
Кстати, а кто-нибудь знает, в каком именно стандарте (RFC, например) описано, какие должны быть соотношения между A/MX/PTR/HELO для того, чтобы сервер считался корректно настроенным?
Файл app/src/main/java/e/a/a/j/a/IAuthRepository.java:
Глубоко не копал, может, URL «esia.gosuslugi.ru/usr_inf?mode=w» не приводит к HTTP-запросу, а используется только как XML Namespace или что-то похожее.
Вопрос знатокам: это намеренная обфускация кода разработчиками или побочный эффект от компиляции? Насколько я вижу, только часть пакетов/классов/методов имеют имена a, b, c, ..., а часть пакетов/классов/методов сумели их сохранить.
SIGABRT можно перепутать с abort (любой из библиотеки или неотловленное исключение), SIGILL, SIGFPE и SIGSEGV можно перепутать с ошибкой на C/C++ (). SIGQUIT почти никем в дикой природе не используется, а сделать Quit from keyboard для сервиса (демона) — надо постараться.
Под «можно перепутать» имеется в виду интерпретация стандартного админа, который будет расследовать проблему «упал рабочий процесс».
На одном из скриншотов есть галочка «Принудительно завершать проблемные процессы». Думаю, местные специалисты и администраторы оценят юмор разработчиков платформы, которые «завершают проблемные процессы» под Linux путем отправки им сигнала SIGSEGV.
Другой вариант — сдастся РКН и уберет сайт из реестра сам. Маловероятно.
> Иначе — сидите под этими и не жалуйтесь.
Еще ближе к реальности следующее: у меня нет знакомых, которые хотят в течение хотя бы года попасть в Думу и бороться с глупостями в режиме один против ста.
А мой домашний провайдер заблокировал доступ к aps.org (American Physical Society). А рабочий — к cloudfront, которым пользуется aps.org. И как
житьработать в течение хотя бы года с тем, что есть?Уголовка за что? За размещение «запрещенной» информации в сети? Или за действия, которые приведут к частичному DoS, в результате чего пострадают пользователи, провайдеры и, частично, ресурсы?
По первому пункту — закон предусматривает только блокировки. Это не очень похоже на уголовку.
По второму пункту — это
дыраошибка в конкретном коммерческом ПО. Я не помню ни одного закона, по которому лицам запрещается вносить DNS-записи для своих доменов. Отмечу, что указанные действия не предполагают несанкционированного вмешательства в чьи-либо сети или системы.PS: У меня есть публичный (доступный из сети Интернет) сервер, на котором корневая зона "." подписана другим (не официальным) ключом DNSSEC. Меня стоит оштрафовать, посадить или расстрелять?
Вопрос состоит в другом.
Типичнуя модель угроз строят, исходя из предположения, что злоумышленник знает все, кроме секрета (ключа).
Передавая ключ в облако, мы автоматически расширяем attack surface.
Более того, рассмотрим просто облако.
Пусть облако шифрует ключи, поэтому дамп БД с ключами бесполезен. Пароли от ключей знает только пользователь, поэтому дамп всех данных со всего облака тоже бесполезен. Тогда возникают вопрос: где происходит процесс расшифровки ключа?
1. В облаке? Злоумышленник может перехватить ключ именно в этот момент. Пользователь не заметит.
2. В браузере пользователя? Тогда можно внедрить код на страницу или в скрипты. Или в Я.метрику. Пользователь не заметит. И у пользователя нет возможности проконтроллировать.
3. В клиентском ПО не для браузера? Кто и как гарантирует, что это ПО не сохранит расшифрованный ключ во временную папку?
4. Используется HSM? Кто докажет, что он не выдаст все ключи по недокументированной команде?
Когда закрытый ключ лежит на диске/флешке/ключе, то этот вопрос остается целиком и полностью под контролем пользователя.
Пользователи самосборных initramfs спят спокойно, ручные пользователи cryptsetup спят спокойно. Что с genkernel?
2. Корректные записи DNS. Злоумышленнику это сделать не сложно. Мы прямо сейчас получаем огромное количество спама от разных доменов .eu, причем все домены имеют совершенно корректно настроенный Postfix (не является open relay), совершенно корректные записи DNS (и MX и PTR) и не имеют сайта. Как бороться — непонятно. Пока помогает лишь массовая блокировка по подсетям датацентров с рассадниками.
4. SPF работает неплохо до тех пор, пока ключевой партнер (фирма в 100-1000 раз большая по размеру) не делает кривые настройки у себя, а потом присылает письмо «У вас слишком суровые правила фильтрации, отключите их».
Кстати, а кто-нибудь знает, в каком именно стандарте (RFC, например) описано, какие должны быть соотношения между A/MX/PTR/HELO для того, чтобы сервер считался корректно настроенным?