android уязвимость доверительного менеджера - PullRequest
6 голосов
/ 16 июня 2020

Я получил очень тревожное электронное письмо от Google:

Мы проверили app name с package name и обнаружили, что ваше приложение использует программное обеспечение, которое содержит уязвимости безопасности для пользователей. Приложения с этими уязвимостями могут раскрыть информацию о пользователе или повредить его устройство, и их можно рассматривать как нарушающие нашу политику в отношении вредоносного поведения.

Ниже приведен список проблем и соответствующие версии APK, обнаруженные в вашем недавнее представление. Перенесите свои приложения, чтобы использовать обновленное программное обеспечение, как можно скорее и увеличьте номер версии обновленного APK.

Версия APK уязвимости Крайний срок исправления TrustManager Дополнительную информацию о TrustManager можно найти в этой справке Google. Центральная статья.

486 14 сентября 2020 г. Уязвимость версии APK Крайний срок исправления Чтобы убедиться, что вы обновились правильно, отправьте обновленную версию своего приложения в Play Console и повторите попытку через пять часов. Мы покажем предупреждающее сообщение, если приложение не было обновлено должным образом.

Хотя эти уязвимости не могут повлиять на каждое приложение, лучше всегда быть в курсе всех исправлений безопасности.

Если у вас есть технические вопросы об уязвимости, вы можете написать в Stack Overflow и использовать тег «android -security». Чтобы уточнить действия, которые необходимо предпринять для решения этой проблемы, вы можете связаться с нашей службой поддержки разработчиков.

Best,

The Google Play Team

The only в приложение версии 486 добавлено шифрование RSA, которое я добавил к некоторым данным.

Это шифрование выполняется следующим образом: я вручную сгенерировал пару ключей RSA, сохранил закрытый ключ на своем сервере и развернул publi c ключ вместе с apk.

Для некоторых запросов в приложении я использую ключ publi c для шифрования данных перед их отправкой через почтовый запрос, используя URLConnection на стороне сервера. расшифровать его и обработать, затем я отправляю ответ пользователю UNENCRYPTED .

, поэтому примите во внимание следующее: 0- в приложении есть только два запроса, которые используют эту технику c 1 - это обновление было сделано, чтобы гарантировать, что все запросы, поступающие на сервер, поступают из моего официального приложения, так как на прошлой неделе я получил 3 DoS-атаки 2- этот запрос существовал целую вечность и всегда использовал стандартный android HTTPSUrlConnection без какого-либо дополнительного шифрования ... теперь я добавил дополнительный уровень шифрования (как это могло сделать приложение менее безопасным?) 3- данные передается совершенно безобидно

Я знаю, что такое MITM-атака, и я делал это целую вечность, чтобы перепроектировать некоторые приложения, я не могу сделать этот тип атаки против моего приложения без изменения скомпилированного кода

При этом, как я могу решить эту проблему, не понижая уровень работы, на выполнение которой у меня ушла одна неделя?

это код:

post.put("p", "test");
            post.put("s", Encrypter.encrypt(userid + "|" + did));
            final String data = SimpleJsonDeserializer.getDefaultJson().toJson(post);
            FirebaseCrashlytics.getInstance().log(data);
            conn = (HttpsURLConnection) new URL(App.CLOUD_FUNCTIONS_HOST + "warsaw?v=2").openConnection();
            conn.setDoInput(true);
            conn.setDoOutput(true);

            conn.setRequestMethod("POST");
            conn.addRequestProperty("accept", "application/json");
            conn.addRequestProperty("content-type", "application/json; charset=utf-8");

            conn.addRequestProperty("content-length", data.length() + "");
            conn.getOutputStream().write(data.getBytes());
            conn.getOutputStream().flush();
            conn.getOutputStream().close();

это класс Encrypter ( который является новым, добавленным на 486)

public final class Encrypter {

    private static Cipher cipher;


    public static void initialize(@NonNull final Context c) {
        if (cipher == null) {
            try {
                cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding");
                X509EncodedKeySpec spec = new X509EncodedKeySpec(Base64.decode("my public key base64 coded".getBytes(), Base64.DEFAULT));
                KeyFactory kf = KeyFactory.getInstance("RSA");
                cipher.init(Cipher.ENCRYPT_MODE, kf.generatePublic(spec));
            } catch (NoSuchAlgorithmException | NoSuchPaddingException | InvalidKeySpecException | InvalidKeyException e) {
                App.shouldNeverHappen(e);
            }
        }
    }

    public static String encrypt(@NonNull final String s) throws IllegalBlockSizeException {

        if (s.isEmpty() || s.length() > 240)
            throw new IllegalBlockSizeException("Data must not be longer than 245 bytes");


        try {
            return new String(Base64.encode(cipher.doFinal(s.getBytes()), Base64.DEFAULT));
        } catch (BadPaddingException e) {
            App.shouldNeverHappen(e);
            return "";
        }

    }

}

Единственный способ использовать «внедрить» вредоносный ключ - это изменить скомпилированный код (что НЕВОЗМОЖНО предотвратить), но даже при этом злоумышленник будет только иметь возможность изменять подпись данных сообщения в запросах SENT что было бы бесполезно для какой-либо фишинг-атаки

Я на 100% уверен, что такое предупреждение помечается некоторой автоматической проверкой кода (на которую Google тратит НУЛЕВЫЕ работы по переоценке вручную), поэтому, поскольку я получил Из-за этой проблемы я развернул несколько версий своего приложения, просто «замаскировав» код, чтобы попытаться не отмечаться при этой автоматической проверке c кода ... пока не удалось.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...