Как удалить cve 2017 0752 со смартфона
Перейти к содержимому

Как удалить cve 2017 0752 со смартфона

  • автор:

Как удалить cve 2017 0752 со смартфона

Изображение

Обсуждение DEXP Ixion E240 Strike 2
DEXP Ixion E240 Strike 2
Описание | Обсуждение »

  • Перед тем как задать вопрос, посмотрите FAQ по Android OS и Глоссарий . Уважайте своё и чужое время.
  • Для обсуждения и поиска сторонних программ/игр пользуйтесь разделами:и.
  • Для сравнения устройства с конкурентами и по вопросам выбора устройств обращайтесь в раздел:Выбор и сравнение.
  • Доступный объем оперативной памяти и памяти для установки приложений обсуждается в теме:Сколько памяти у вас в аппарате?
  • Результаты тестов производительности Android устройств смотрите в теме:Benchmark
  • Перед размещением фотографии ознакомьтесь с темойРабота с изображениями на форуме
  • Сообщения, не относящиеся к теме обсуждения (оффтоп), удаляются без предупреждения.

Технические характеристики

Прикрепленное изображениеПрикрепленное изображение

ОС: Android 6.0
Сети: GSM, 3G (2х microSim)
Экран: 4 дюйм. (TFT/800х480)
Процессор: MediaTek MT6580 (4х1.3Ггц, 28nm, 32bit, Mali-400 MP2)
Оперативная память: 512 Мб
Постоянная память: 8 Гб
Слот для карт памяти microSDHC: до 32 Гб
Камеры: 2 Мпкс (LED вспышка), макс. видео запись 720p@30fps (H264, моно)/ 0.3 Мпкс (фронтальная)
Интерфейсы: Wi-Fi 802.11b/g/n, Bluetooth 4.0, GPS, FM, 3.5мм (для наушников)
Датчики: G-сенсор, датчик приближения
Емкость аккумулятора: 1400 мАч (съемный)
Размеры (ВxШxТ): 123*65*9.8мм
Вес: 105гр
Комплектация: Зарядное устройство, кабель USB, руководство пользователя, гарантийный талон

Драйвера и утилиты

Внимание создателей / пользователей прошивок !

Условные обозначения:
Прикрепленное изображение— Прошивка рекомендуется к установке, нет или почти нет багов.
Прикрепленное изображение— В прошивке есть баги и недоработки.
Прикрепленное изображение— Бета версия прошивки, крайне не стабильная, не рекомендуется к установке, предназначается для разработчиков(ромоделов).

Оф. прошивки

Оф.прошивки
Улучшенный сток 1.2

Каст. прошивки

MokeeOS 7.1.1
OktOS

Android 6.0


Прикрепленное изображение Cyanogenmod 13 Final
Прикрепленное изображениеiOS 10
Прикрепленное изображение X OS
Прикрепленное изображение FreeMe :girl_triniti:

Прикрепленное изображение EMUI
Прикрепленное изображение MIUI 8.1

Изменения шапки
DevFAQ
В теме нет куратора. По вопросам наполнения шапки обращайтесь к модераторам раздела через кнопку под сообщениями, на которые необходимо добавить ссылки.

Сообщение отредактировал Lexx808 — 08.03.22, 12:42

Причина редактирования: Убрал HOMTOM и Ulefone U007
02.08.16, 11:28 | #2


Постоянный
Реп: ( 4 )

Стоит брать данный девайс ?
Сколько на самом деле на этом смартфоне ram (оперативной памяти ?)
Ну и внутренней ? (rom)

Сообщение отредактировал Engineer81 — 02.08.16, 11:30

05.08.16, 13:43 | #3


Постоянный
Реп: ( 8 )
Engineer81 @ 02.08.2016, 17:28

Стоит брать данный девайс ?
Сколько на самом деле на этом смартфоне ram (оперативной памяти ?)
Ну и внутренней ? (rom)

держу в руках сабж. Отвечаю:

Прикрепленное изображение

Прикрепленное изображение

Сообщение отредактировал АлександрL — 15.10.16, 09:54

Причина редактирования: Картинки под спойлер!
07.08.16, 20:40 | #4


Постоянный
Реп: ( 2 )

Что-то у меня с основной камерой ерунда. Максимальное разрешение снимка 640×480. И в настройках так же можно выбрать либо VGA, либо QVGA.

08.08.16, 06:00 | #5


Постоянный
Реп: ( 8 )
riv_2005,
У него основная камера 0,3 Мпх. А для видеозвонка — 2 Мпх
08.08.16, 16:08 | #6


Постоянный
Реп: ( 2 )
Не, основная 2, а для видео 0.3. В техподдержке обещали обновление софта выпустить.
18.08.16, 17:51 | #7


Постоянный
Реп: ( 7 )
кто-нибудь пытался портануть кастом рекавери на Это?
19.08.16, 13:24 | #8


Постоянный
Реп: ( 155 )

Вот попробуйте. После прошивки сразу загружайтесь в рекавери. И ссылка на прошивки ftp://dev.dexp.club/Smartphones/Ixion%20E240/

Прикрепленные файлы
23.08.16, 12:05 | #9


Постоянный
Реп: ( 7 )
слетел серийный номер. после прошивки preloader`а, наверно. восстановить не получается :wallbash:
24.08.16, 08:32 | #10


Постоянный
Реп: ( 0 )
Как рут на сие чудо получить? Уже всё перепробовал.
24.08.16, 08:47 | #11


Постоянный
Реп: ( 7 )
asasinsion @ 24.08.2016, 11:32
Как рут на сие чудо получить?

шей флештулом twrp и в нем ставь supersu.
08.09.16, 11:24 | #12


Постоянный
Реп: ( 2 )
А как рекавери шить?
09.09.16, 16:04 | #13


Постоянный
Реп: ( 7 )
Не видет комп СД карту.Подскажите как вылечить.
11.09.16, 06:12 | #14


Постоянный
Реп: ( 2 )
А можно без пк рут получить?
11.09.16, 07:19 | #15


Постоянный
Реп: ( 2 )
Я не понял как прошить
18.09.16, 11:54 | #16


Активный
Реп: ( 2 )

граждане ловите супер су для нашей молели. Напоминаю установка из рекавери :thank_you:
:yes2: дерзайте :happy:

Прикрепленные файлы
21.09.16, 17:41 | #17


Постоянный
Реп: ( 23 )
На него Cyanogenmod есть? После установки рекавери уже можно обойтись без компа?
21.09.16, 19:45 | #18


Супермодератор
Реп: ( 1256 )
Тема перенесена в подраздел DEXP
Прошу всех ознакомиться с Правилами раздела «Android — Устройства»
15.10.16, 06:17 | #19


Постоянный
Реп: ( 14 )
Marshall55 @ 12.10.2016, 22:29

Это фича или ? У меня в мессенджерах кнопка отправки не спервого раза работает, как будто подвисает перед отправкой.?
.
Актуальненько

Гайд по прошивке аппарата:

1. Выключаем тел.
2. Вынимаем/вставляем батарею (. ) не включаем.
3. Скачиваем TWRP и SP FT и стоковую прошивку с 1/2 страницы. (Обязательно).
4. Разархивируем прошивку в C:\»прошивка» весь путь до файла должен быть латиницей.
5. Файл TWRP.img переименовываем в recovery.img и копируем с заменой в папку с прошивкой.
6. Заходим в sp flash tool, выбираем scatter из файла с прошивкой.
7. Заходим в форматирование жмем format и только после подкл. Телефон.
8. После откл. Тел от кабеля, телефон не включаем.
9. Идем в download, там выбираем download only и ставим везде галочки.
10. Жмем dwnload и опять подключаем телефон.
.
PROFIT.
P.s — если вылезет ошибка с каким то маленьким текстом при самой прошивке. То снемите галочку с preloader, прошейте и потом оставьте только галочку preloader и опять прошейте.

ВНИМАНИЕ: При прошивке слетает IMEI. Восстанавливается легко, через рут и прогу chamelephone.

Сообщение отредактировал АлександрL — 15.10.16, 10:03

Причина редактирования: В шапке
17.10.16, 17:25 | #20


Постоянный
Реп: ( 5 )

Гайз, а есть возможность подрубить какую-нибудь темную тему на смарт?

Прямо таки глаз не нарадуется от того как смартфон стал быстрее работать. :clap: Еще подрубил сваппер рут, но только пока что вроде не особо ощущаю разницы что без него, что с ним)

Сообщение отредактировал Marshall55 — 17.10.16, 17:37

Причина редактирования: Добавление информации
18.10.16, 13:18 | #21


Постоянный
Реп: ( 5 )
dino64 @ 18.10.2016, 07:41
Так объясните почему стал быстрее? Из за рута или новой прошивки? Не понятно.

После установки рутбустера, до этого смарт мог тупо начать дико лагать минут на 10, пока такого не случалось после прошивки+рутбустер

Разбор уязвимостей EvilParcel

В середине апреля мы опубликовали новость о троянце Android.InfectionAds.1, который эксплуатировал несколько критических уязвимостей в ОС Android. Одна из них — CVE-2017-13156 (также известна как Janus) — позволяет вредоносной программе заражать APK-файлы, не повреждая их цифровую подпись.

Другая — CVE-2017-13315. Она дает троянцу расширенные полномочия, и тот может самостоятельно устанавливать и удалять приложения. Детальный анализ Android.InfectionAds.1 размещен в нашей вирусной библиотеке, с ним можно ознакомиться здесь. Мы же подробнее остановимся на уязвимости CVE-2017-13315 и посмотрим, что она из себя представляет.

CVE-2017-13315 относится к группе уязвимостей, получивших общее наименование EvilParcel. Они обнаруживаются в различных системных классах ОС Android. Из-за ошибок в последних при обмене данными между приложениями и системой становится возможной подмена этих данных. Вредоносные программы, эксплуатирующие уязвимости EvilParcel, получают более высокие привилегии и с их помощью могут делать следующее:

  • устанавливать и удалять приложения с любыми разрешениями без подтверждения пользователя;
  • при использовании совместно с другими уязвимостями заражать установленные на устройстве программы и подменять «чистые» оригиналы инфицированными копиями;
  • сбрасывать код блокировки экрана Android-устройства;
  • сбрасывать PIN-код блокировки экрана Android-устройства.
  • CVE-2017-0806 (ошибка в классе GateKeeperResponse), опубликована в октябре 2017 г.;
  • CVE-2017-13286 (ошибка в классе OutputConfiguration, опубликована в апреле 2018 г.;
  • CVE-2017-13287 (ошибка в классе VerifyCredentialResponse), опубликована в апреле 2018 г.;
  • CVE-2017-13288 (ошибка в классе PeriodicAdvertizingReport), опубликована в апреле 2018 г.;
  • CVE-2017-13289 (ошибка в классе ParcelableRttResults), опубликована в апреле 2018 г.;
  • CVE-2017-13311 (ошибка в классе SparseMappingTable), опубликована в мае 2018 г.;
  • CVE-2017-13315 (ошибка в классе DcParamObject), опубликована в мае 2018 г.

Предпосылки для возникновения уязвимостей EvilParcel

Давайте разберемся, как возникают уязвимости EvilParcel. Прежде всего, рассмотрим некоторые особенности работы Android-приложений. В ОС Android все программы взаимодействуют друг с другом, а также с самой операционной системой через отправку и получение объектов типа Intent. Эти объекты могут содержать произвольное количество пар «ключ-значение» внутри объекта типа Bundle.

При передаче Intent объект Bundle преобразуется (сериализуется) в байтовый массив, облаченный в Parcel, а при чтении ключей и значений из сериализованного Bundle тот автоматически десериализуется.

В Bundle ключом выступает строка, а значение может быть практически любым. Например, примитивным типом, строкой или контейнером, содержащим примитивные типы или строки. Кроме того, он может быть и объектом типа Parcelable.

Таким образом, в Bundle можно поместить объект произвольного типа, реализующий интерфейс Parcelable. Для этого потребуется реализовать методы writeToParcel() и createFromParcel() для сериализации и десериализации объекта.

В качестве наглядного примера создадим простой сериализованный Bundle. Напишем код, который поместит в Bundle три пары «ключ-значение» и сериализует его:

Bundle demo = new Bundle();
demo.putString(«String», «Hello, World!»);
demo.putInt(«Integer», 42);
demo.putByteArray(«ByteArray», new byte[]);
Parcel parcel = Parcel.obtain();
parcel.writeBundle(demo);

После выполнения этого кода мы получим Bundle следующего вида:

Рисунок 1. Структура сериализованного объекта Bundle.

Обратим внимание на следующие особенности сериализации Bundle:

  • все пары ключ-значение записаны друг за другом;
  • перед каждым значением указан его тип (13 для массива байт, 1 для Integer, 0 для строки и так далее);
  • перед данными переменной длины указан их размер (длина для строки, количество байт для массива);
  • все значения записаны с выравниванием 4 байта.

Казалось бы, в чем может быть проблема? А она – в том, что в некоторых системных классах, реализующих Parcelable, в методах createFromParcel() и writeToParcel() могут встречаться ошибки. В этих классах количество прочитанных байтов в методе createFromParcel() будет отличаться от количества записанных байтов в методе writeToParcel(). Если поместить объект такого класса внутрь Bundle, границы объекта внутри Bundle после повторной сериализации изменятся. И именно здесь создаются условия для эксплуатации уязвимости EvilParcel.

Приведем пример класса с подобной ошибкой:

class Demo implements Parcelable < byte[] data; public Demo() < this.data = new byte[0]; >protected Demo(Parcel in) < int length = in.readInt(); data = new byte[length]; if (length >0) < in.readByteArray(data); >> public static final Creator CREATOR = new Creator() < @Override public Demo createFromParcel(Parcel in) < return new Demo(in); >>; @Override public void writeToParcel(Parcel parcel, int i) < parcel.writeInt(data.length); parcel.writeByteArray(data); >> 

Если размер массива data будет равен 0, то при создании объекта в createFromParcel() будет прочитан один int (4 байта), а в writeToParcel() будет записано два int (8 байт). Первый int будет записан явным вызовом writeInt. Второй int будет записан при вызове writeByteArray(), поскольку перед массивом в Parcel всегда записывается его длина (см. Рисунок 1).

Ситуации, когда размер массива data равен 0, возникают редко. Но даже когда это случается, программа все равно продолжает работать, если за один раз передавать в сериализованном виде только один объект (в нашем примере — объект Demo). Поэтому подобные ошибки, как правило, остаются незамеченными.

Теперь попробуем поместить объект Demo с нулевой длиной массива в Bundle:

Рисунок 2. Результат добавления объекта Demo с нулевой длиной массива в Bundle.

Рисунок 3. Объект Bundle после сериализации.

Попробуем его десериализовать:

Рисунок 4. После десериализации объекта Bundle.

Каков же результат? Рассмотрим фрагмент Parcel:

Рисунок 5. Структура Parcel после десериализации Bundle.

Из рисунков 4 и 5 мы видим, что при десериализации в методе createFromParcel был прочитан один int вместо двух записанных ранее. Поэтому все последующие значения из Bundle были прочитаны неверно. Значение 0x0 по адресу 0x60 было прочитано как длина следующего ключа. А значение 0x1 по адресу 0x64 было прочитано как ключ. При этом значение 0x31 по адресу 0x68 было прочитано как тип значения. В Parcel нет значений, тип которых равен 0x31, поэтому readFromParcel() добросовестно отрапортовал об ошибке (exception).

Как это может использоваться на практике и стать уязвимостью? Давайте посмотрим! Описанная выше ошибка в системных классах Parcelable позволяет конструировать Bundle, которые при первой и повторной десериализациях могут отличаться. Чтобы это продемонстрировать, модифицируем предыдущий пример:

Parcel data = Parcel.obtain(); data.writeInt(3); // 3 entries data.writeString("vuln_class"); data.writeInt(4); // value is Parcelable data.writeString("com.drweb.testbundlemismatch.Demo"); data.writeInt(0); // data.length data.writeInt(1); // key length -> key value data.writeInt(6); // key value -> value is long data.writeInt(0xD); // value is bytearray -> low(long) data.writeInt(-1); // bytearray length dummy -> high(long) int startPos = data.dataPosition(); data.writeString("hidden"); // bytearray data -> hidden key data.writeInt(0); // value is string data.writeString("Hi there"); // hidden value int endPos = data.dataPosition(); int triggerLen = endPos - startPos; data.setDataPosition(startPos - 4); data.writeInt(triggerLen); // overwrite dummy value with the real value data.setDataPosition(endPos); data.writeString("A padding"); data.writeInt(0); // value is string data.writeString("to match pair count"); int length = data.dataSize(); Parcel bndl = Parcel.obtain(); bndl.writeInt(length); bndl.writeInt(0x4C444E42); // bundle magic bndl.appendFrom(data, 0, length); bndl.setDataPosition(0);

Этот код создает сериализованный Bundle, который содержит в себе уязвимый класс. Посмотрим на результат выполнения данного кода:

Рисунок 6. Создание Bundle с уязвимым классом.

После первой десериализации этот Bundle будет содержать следующие ключи:

Рисунок 7. Результат десериализации Bundle с уязвимым классом.

Теперь вновь сериализуем полученный Bundle, затем опять десериализуем его и посмотрим на список ключей:

Рисунок 8. Результат повторной сериализации и десериализации Bundle с уязвимым классом.

Что мы видим? В Bundle появился ключ hidden (со строковым значением «Hi there!»), которого раньше не было. Рассмотрим фрагмент Parcel этого Bundle, чтобы понять, почему так произошло:

Рисунок 9. Структура Parcel объекта Bundle с уязвимым классом после двух циклов сериализации-десериализации.

Здесь суть уязвимостей EvilParcel становится более понятной. Возможно создать специально сформированный Bundle, который будет содержать уязвимый класс. Изменение границ такого класса позволит разместить в этом Bundle любой объект – например, Intent, который появится в Bundle только после второй десериализации. Это даст возможность скрыть Intent от механизмов защиты операционной системы.

Эксплуатация EvilParcel

Android.InfectionAds.1 с помощью CVE-2017-13315 самостоятельно устанавливал и удалял программы без вмешательства владельца зараженного устройства. Но как это происходит?

В 2013 году была обнаружена ошибка 7699048, также известная как Launch AnyWhere. Она позволяла стороннему приложению запускать произвольные activity от имени более привилегированного пользователя system. На диаграмме ниже показан механизм ее действия:

Рисунок 10. Схема работы ошибки 7699048.

С помощью этой уязвимости приложение-эксплойт может реализовать сервис AccountAuthenticator, который предназначен для добавления новых аккаунтов в операционную систему. Благодаря ошибке 7699048 эксплойт способен запускать activity на установку, удаление, замену приложений, сброс PIN-кода или Pattern Lock и делать другие неприятные вещи.

Корпорация Google устранила эту брешь, запретив запуск из AccountManager произвольных activity. Теперь AccountManager разрешает запуск только activity, исходящих от того же самого приложения. Для этого выполняется проверка и сопоставление цифровой подписи программы, инициировавшей запуск activity, с подписью приложения, в котором находится запускаемая activity. Выглядит это так:

if (result != null && (intent = result.getParcelable(AccountManager.KEY_INTENT)) != null) < /* * The Authenticator API allows third party authenticators to * supply arbitrary intents to other apps that they can run, * this can be very bad when those apps are in the system like * the System Settings. */ int authenticatorUid = Binder.getCallingUid(); long bid = Binder.clearCallingIdentity(); try < PackageManager pm = mContext.getPackageManager(); ResolveInfo resolveInfo = pm.resolveActivityAsUser(intent, 0, mAccounts.userId); int targetUid = resolveInfo.activityInfo.applicationInfo.uid; if (PackageManager.SIGNATURE_MATCH != pm.checkSignatures(authenticatorUid, targetUid)) < throw new SecurityException( "Activity to be started with KEY_INTENT must " + "share Authenticator's signatures"); >> finally < Binder.restoreCallingIdentity(bid); >> 

Казалось бы, проблема решена, однако не все здесь так гладко. Оказалось, что данный фикс можно обойти, используя уже хорошо нам известную уязвимость EvilParcel CVE-2017-13315! Как мы уже знаем, после исправления Launch AnyWhere система проверяет цифровую подпись приложения. Если эта проверка выполняется успешно, Bundle передаётся в IAccountManagerResponse.onResult(). При этом вызов onResult() происходит через механизм IPC, поэтому Bundle снова сериализуется. В реализации onResult() происходит следующее:

/** Handles the responses from the AccountManager */ private class Response extends IAccountManagerResponse.Stub < public void onResult(Bundle bundle) < Intent intent = bundle.getParcelable(KEY_INTENT); if (intent != null && mActivity != null) < // since the user provided an Activity we will silently start intents // that we see mActivity.startActivity(intent); // leave the Future running to wait for the real response to this request >// > // > 

Далее Bundle извлекается ключ intent и запускается activity уже без проверок. В результате для запуска произвольной activity с правами system достаточно лишь сконструировать Bundle таким образом, чтобы при первой десериализации поле intent было скрыто, а при повторной – появилось. А, как мы уже убедились, как раз эту задачу и выполняют уязвимости EvilParcel.

На данный момент все известные уязвимости этого типа исправлены фиксами в самих уязвимых классах Parcelable. Однако нельзя исключать повторного появления уязвимых классов в будущем. Реализация Bundle и механизм добавления новых аккаунтов по-прежнему остаются теми же, что и раньше. Они до сих пор позволяют создать точно такой же эксплойт при обнаружении (или появлении новых) уязвимых классов Parcelable. Более того, реализация этих классов все еще выполняется вручную, и за соблюдением постоянной длины сериализованного объекта Parcelable должен следить программист. А это — человеческий фактор со всеми вытекающими. Однако будем надеяться, что подобных ошибок будет как можно меньше, и уязвимости EvilParcel не станут докучать пользователям Android-устройств.

Проверить свое мобильное устройство на наличие уязвимостей EvilParcel можно с помощью нашего антивируса Dr.Web Security Space. Встроенный в него «Аудитор безопасности» сообщит о выявленных проблемах и даст рекомендации по их устранению.

  • Блог компании Доктор Веб
  • Антивирусная защита

Самые опасные уязвимости Android

Как известно, операционные системы разрабатываются людьми. Кое-кто, кто смотрит РЕН ТВ, впрочем уверен, что Android создали рептилоиды, однако это не так: в мобильной платформе Google на сегодняшний день обнаружено множество ошибок, допустить которые могли только представители вида homo sapiens.

Некоторые из этих багов представляют собой полноценные уязвимости и могут использоваться как для несанкционированного доступа к файловой системе смартфона, так и для распространения вредоносного ПО.

Самые опасные уязвимости Android

Если верить официальной статистике Google, на сегодняшний день среди версий Android наиболее распространена Nougat — редакция мобильной платформы за номером 7.0 и 7.1 установлена в совокупности на 28,2% устройств. Вторую позицию уверенно занимает Android 8.0 и 8.1 Oreo с показателем 21,5%. На третьем месте закрепилась шестая версия Marshmallow — она работает на 21,3% девайсов. Android 5.0 и 5.1 Lollipop установлены суммарно на 17,9% устройств, а замыкает группу лидеров Android 4.4 KitKat с показателем 7,6% пользователей.

Согласно информации с сайта cvedetails.com, на сегодняшний день в Android насчитывается 2146 уязвимостей, при этом число выявленных багов начало экспоненциально расти примерно с 2014 года.

Самые критические уязвимости Android

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

Самая критические и опасные уязвимости Android

Самая первая уязвимость Android была обнаружена еще в октябре 2008 года в прошивке коммуникатора HTC T-Mobile G1. При просмотре веб-страниц с определенным содержимым ошибка в ПО позволяла выполнить вредоносный код, отслеживающий использование клавиатуры гаджета. Теоретически таким образом можно было реализовать кейлоггер, фиксирующий нажатия кнопок, и собирать вводимую пользователем при веб-серфинге информацию. Эта уязвимость представляла опасность только для одной-единственной модели коммуникатора, но само ее наличие наглядно показало: Android — не настолько безопасная и защищенная система, как считалось ранее.

С ростом популярности операционной системы энтузиасты и исследователи отыскивали все новые и новые баги в различных ее версиях. Безусловно, в рамках одной статьи мы не сможем охватить все две тысячи с лишним уязвимостей, обнаруженных за все время существования Android. Поэтому сосредоточимся только на самых интересных и опасных из них, причем — только в актуальных на данный момент версиях Android (тех, что сейчас еще могут встретиться в жизни).

Самым «дырявым» оказалось четвертое поколение Android, начиная с версии 4.4 KitKat. С него, пожалуй, и начнем наш обзор уязвимостей, выявленных в разное время в этой платформе.

BlueBorne

CVE: CVE-2017-1000251, CVE-2017-1000250, CVE-2017-0781, CVE-2017-0782, CVE-2017-0785 и CVE-2017-0783
Уязвимые версии Android: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2, 8.0
Для эксплуатации требуется: атакующий должен находиться на расстоянии не более десяти метров от уязвимого устройства, а на уязвимом устройстве должен быть включен Bluetooth
Возможный результат: выполнение произвольного кода с привилегиями ядра системы, утечка данных

Это не отдельная уязвимость, а целый набор ошибок в стеке Bluetooth современных операционных систем, среди которых числится и Android. Серьезные баги содержатся в коде системной функции l2cap_parse_conf_rsp ядра Linux, причем их можно обнаружить во всех версиях ядра, начиная с 3.3. Если в системе включена защита от переполнения стека CONFIG_CC_STACKPROTECTOR, их использование приводит к возникновению критической ошибки в работе ядра.

Уязвимость CVE-2017-1000251 выявлена в модуле ядра под названием L2CAP, который отвечает за работу стека протокола Bluetooth. Еще одна уязвимость в стеке этого протокола получила обозначение CVE-2017-0783. Если на атакуемом девайсе включена подсистема Bluetooth, с их помощью можно удаленно передать на него специальным образом сформированные пакеты информации. Такие пакеты могут содержать вредоносный код, который выполнится в Android с привилегиями ядра системы. При этом для реализации атаки не потребуется предварительно сопрягать устройства или включать на них режим обнаружения. Достаточно, чтобы атакующий находился на расстоянии не более десяти метров от уязвимого устройства.

Поскольку взаимодействующие с протоколом Bluetooth компоненты ОС по умолчанию имеют высокие системные привилегии, эксплуатация этих уязвимостей теоретически позволяет получить полный контроль над атакуемым смартфоном и планшетом, включая доступ к хранящимся на устройстве данным, подключенным сетям и файловой системе. Также с помощью BlueBorne технически можно реализовывать атаки типа man-in-the-middle.

К BlueBorne также относят уязвимость CVE-2017-1000250 в стеке BlueZ Linux-реализации протокола Service Discovery Protocol (SDP). Эксплуатация уязвимости CVE-2017-1000250 может привести к утечке данных. Уязвимости CVE-2017-0781, CVE-2017-0782 и CVE-2017-0785 относятся к самой ОС Android, при этом с помощью первых двух вредоносное приложение может получить в системе привилегии ядра, а последняя позволяет реализовать утечку данных.

Для устранения уязвимостей BlueBorne 9 сентября 2017 года компания Google выпустила обновление безопасности. Также они не страшны устройствам, на которых используется режим Bluetooth Low Energy.

Extra Field

CVE: нет
Уязвимые версии Android: 2.3, 4.0, 4.1, 4.2, 4.3, 4.4
Для эксплуатации требуется: модифицированное приложение
Возможный результат: выполнение произвольного кода

Все приложения для Android распространяются в формате .APK и представляют собой ZIP-архив с тем отличием, что они имеют специальную цифровую подпись. Внутри находятся необходимые для работы компоненты, которые в процессе установки приложения извлекаются, а их контрольные суммы проверяются по эталонным значениям. С помощью уязвимости Extra Field злоумышленник может изменить содержимое установочного пакета APK, не повредив его цифровую подпись.

Внутри архива .APK располагается файл classes.dex, в котором содержится скомпилированный код приложения и набор служебных полей. Среди них есть:

  • поле, хранящее имя файла с расширением;
  • размер файла;
  • поле Extra Field, в котором записан сам исполняемый код;
  • таблица со списком используемых им классов.

Если в поле заголовка записать исходное значение без первых трех байт, значение длины поля Extra Field также изменится, благодаря чему появляется возможность дописать туда произвольный код, например перечислить классы, используемые троянской частью приложения. После этого можно добавить в архив, помимо оригинального classes.dex, его вредоносную копию, часть кода которой будет храниться в «расширенном» поле Extra Field оригинального classes.dex. При установке программы система прочитает содержимое видоизмененных полей, и, поскольку в них перечислены классы из модифицированного classes.dex, на устройство будет установлен именно этот файл.

Таким образом, уязвимость позволяет «подсадить» троянца в любое легитимное приложение с валидной цифровой подписью, разве что размер вредоносного модуля будет ограничен максимальным размером файла classes.dex в 65 533 байт. Уязвимость была обнаружена в начале июля 2013 года и была устранена в версиях Android, выпущенных позже этой даты.

Fake ID

CVE: нет
Уязвимые версии Android: 2.2, 2.3, 4.0, 4.1, 4.2, 4.3, 4.4
Для эксплуатации требуется: приложение, подписанное специальным образом сформированной цифровой подписью
Возможный результат: установка и запуск вредоносного приложения, утечка данных

Эту уязвимость обнаружили в Android 2.2, и она была актуальна вплоть до версии 4.4. Ошибка, соответствующая этой уязвимости, получила внутренний номер 13678484 и в основном устранялась патчами, которые выпускали сами производители устройств.

Как уже упоминалось, все .APK-файлы в Android используют цифровую подпись. Подпись приложения может быть взаимосвязана с цифровой подписью издателя программы. Все эти подписи используют инфраструктуру открытых ключей PKI (Public Key Infrastructure). С помощью цифровой подписи операционная система определяет, какие возможности и привилегии могут быть у приложения, с какими компонентами ОС оно может взаимодействовать, какие системные функции использовать, имеет ли оно право скачивать и устанавливать обновления и так далее.

Применяемые при проверке подписи приложения цифровые сертификаты (электронные документы, в которых хранится цифровой ключ) издаются специальными удостоверяющими центрами. Если система доверяет удостоверяющему центру, она автоматически доверяет и всем изданным им сертификатам, которые использует приложение.

При проверке (валидации) цифровой подписи приложения операционная система использует открытый ключ разработчика программы. Чтобы убедиться в действительности этого ключа, требуется выполнить проверку соответствующего сертификата удостоверяющего центра. Это называется проверкой цепочки сертификатов. Уязвимость заключается в том, что в процессе установки приложения ранние версии Android не выполняли такую проверку вовсе.

В качестве практической реализации уязвимости можно привести такой пример. Если приложение подписано двумя цифровыми сертификатами: подлинным и поддельным, то при его установке будет создана цифровая подпись, использующая оба сертификата. В результате приложение сможет, например, скачивать и устанавливать вредоносные обновления, которые не будут проверяться на безопасность, если разработчик подпишет их с помощью того же недостоверного сертификата.

Janus

CVE: CVE-2017-13156
Уязвимые версии Android: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2
Для эксплуатации требуется: модифицированное приложение
Возможный результат: установка и запуск вредоносного приложения, утечка данных

Еще одна уязвимость за номером CVE-2017-13156, оперирующая с цифровыми подписями приложений Android, только актуальна она для более свежих версий операционной системы — 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1 и 7.1.2. С использованием Janus можно внедрить в .APK-архив исполняемый dex-файл, сохранив при этом оригинальную цифровую подпись приложения. Дыра кроется в системе проверки цифровой подписи на основе JAR, на смену которой в Android 7.0 пришла технология Signature Scheme v2. Тем не менее даже в седьмом и отчасти восьмом поколении Android уязвимость могут использовать старые приложения, не применяющие новый метод верификации, а также некоторые программы, загруженные не из официального каталога Google Play.

ObjectInputStream Serialization

CVE: CVE-2014-7911
Уязвимые версии Android: 1.0–4.4.4
Для эксплуатации требуется: специальное приложение или модуль приложения
Возможный результат: аварийное завершение критически важных системных процессов

Эта уязвимость, которой подвержены все версии Android до 5.0, получила обозначение CVE-2014-7911. Ошибка кроется в механизме проверки сериализации получаемых объектов системным компонентом luni/src/main/java/java/io/ObjectInputStream.

Сериализация — это способность некоторых объектов трансформироваться в последовательность байтов, из которой они потом могут быть восстановлены в первоначальном виде (обратная процедура называется десериализацией). Процедура сериализации обычно применяется для сохранения данных или передачи их другому процессу либо трансляции по сети.

С использованием уязвимости можно выполнить десериализацию любого объекта с открытым конструктором без параметров, даже если он не отвечает критериям для сериализации. Если этот объект использует метод finalize, то в случае его удаления сборщик мусора вызовет этот метод, в результате чего исполняется хранящийся в объекте код. Таким образом можно атаковать системные процессы Android, вызывая их аварийное завершение, в том числе убивать критически важные системные процессы.

OpenSSLX509Certificate

CVE: CVE-2015-3837
Уязвимые версии Android: 4.3–5.1
Для эксплуатации требуется: специальное приложение или модуль приложения
Возможный результат: выполнение произвольного кода с системными привилегиями

Уязвимости OpenSSLX509Certificate, она же CVE-2015-3837, подвержены версии Android с 4.3 по 5.1 включительно. С помощью этого бага можно повысить привилегии вредоносного процесса.

Ошибка в системном компоненте OpenSSLX509Certificate позволяет скомпрометировать системный процесс system_server и выполнить любой код с привилегиями system (UID 1000). Таким образом можно, например, подменить любое установленное ранее приложение (кроме компонент ОС), сохранив вместо него другую программу.

PendingIntent

CVE: CVE-2014-8609
Уязвимые версии Android: 4.0–4.4.4
Для эксплуатации требуется: специальное приложение или модуль приложения
Возможный результат: выполнение в системе любой команды

Эта уязвимость с номером CVE-2014-8609 выявлена в Android 4.0–4.4.4. Ошибка содержится в методе addAccount файла AddAccountSettings.java (расположенного в src/com/android/settings/accounts/), который является частью подсистемы управления учетными записями приложений.

Некоторые приложения Android могут использовать учетные данные юзера для автоматической авторизации в различных интернет-сервисах. В этом случае пользователю достаточно указать свои логин и пароль один раз, после чего они регистрируются в специальном разделе системных настроек «Аккаунты», к которому приложение обращается всякий раз, когда ему необходимо пройти аутентификацию.

При создании такой учетной записи ОС передает приложению различные параметры, среди которых имеется параметр PendingIntent. Из-за ошибки в реализации вызываемого при регистрации аккаунта метода addAccount система не проверяет значения этого поля, поэтому злоумышленник может передать в PendingIntent фактически любую команду, которая будет выполнена с теми же привилегиями, что и направившее его приложение «Настройки», — системными.

Можно сформировать команду на удаление хранящихся на устройстве файлов или последовательность байтов, которая будет воспринята системой как входящее SMS-сообщение. Например, если в параметре PendingIntent будет передана команда android.intent.action.MASTER_CLEAR, Android послушно выполнит полный системный сброс с уничтожением всей хранящейся на устройстве информации.

StageFright

CVE: CVE-2015-1538
Уязвимые версии Android: 2.2–5.1.1
Для эксплуатации требуется: передать на устройство специальным образом скомпонованный MP4-файл
Возможный результат: выполнение произвольного кода с системными привилегиями

Эта уязвимость актуальна для всех версий Android с 2.2 до 5.1.1. Ошибка обнаружилась в системной библиотеке Stagefright, которая обеспечивает воспроизведение медиафайлов в формате MP4.

Если на уязвимое устройство удается доставить специальным образом скомпонованный MP4-файл (например, в MMS-сообщении), то из-за ошибки в обработчике SampleTable.cpp встроенный в этот файл произвольный код будет выполнен с системными привилегиями, даже если пользователь просто откроет папку, в которой такой файл хранится.

StageFright 2.0

CVE: CVE-2015-6602
Уязвимые версии Android: 4.1–5.1.1
Для эксплуатации требуется: передать на устройство специальным образом скомпонованный MP3- или MP4-файл
Возможный результат: выполнение произвольного кода с системными привилегиями

Несмотря на схожесть названия, эта уязвимость прячется в другом компоненте — в приложении mediaserver, точнее в обработчике тегов ID3v2. Уязвимы версии Android с 4.1 по 5.1.1.

Для использования уязвимости достаточно любым способом доставить на атакуемое устройство специальным образом модифицированный MP3- или MP4-файл. Во время чтения содержащихся в таком файле тегов ID3v2 происходит переполнение буфера, в результате чего выполняется встроенный в файл произвольный код с системными привилегиями.

SIM Toolkit

CVE: CVE-2015-3843
Уязвимые версии Android: 5.1
Для эксплуатации требуется: специальное приложение или модуль приложения
Возможный результат: перехват и подмена команд, отправляемых SIM-картой операционной системе

В Android есть встроенный фреймворк SIM Application Toolkit (STK), который позволяет SIM-карте выполнять в системе определенный набор команд. Таким образом, в частности, формируется SIM-меню оператора связи.

Уязвимость позволяет перехватывать команды, отправляемые SIM-картой операционной системе, а также подменять их. Вредоносное приложение может передать классу com.android.stk.StkCmdReceiver специально созданный объект parcelable. Получатель не проверяет подлинность отправителя, при этом действие android.intent.action.stk.command не объявлено в манифесте как защищенное, благодаря чему можно эмулировать отсылку команд SIM-картой.

Например, если SIM-карта формирует на экране устройства сообщение с подтверждением действий пользователя, оно будет содержать кнопку ОK. Такие сообщения используются для подтверждения отправки USSD-запросов, транзакций, действий с хранящимися на карте контактами и так далее.

Вредоносное приложение может вызвать действие android.intent.action.stk.command и отобразит на экране поверх настоящего поддельное окно, содержащее произвольный текст. При нажатии кнопки ОK вызывается метод sendResponse() с флагом true, и это событие — нажатие кнопки — передается SIM-карте, ожидающей реакции пользователя. При этом событие будет обработано так, как если бы оно поступило от настоящего диалогового окна.

ToastOverlay

CVE: CVE-2017-0752
Уязвимые версии Android: 4.0–7.1.2
Для эксплуатации требуется: приложение с разрешением BIND_ACCESSIBILITY_SERVICE
Возможный результат: получение полного контроля над окном типа TYPE_TOAST

Эта уязвимость была обнаружена в 2017 году и затрагивает все версии Android с 4.0 по 7.1.2 включительно. Ошибку разработчики допустили в подсистеме оверлеев — окон, способных отображаться поверх других экранных форм.

Использующему уязвимость приложению достаточно объявить в манифесте только одно разрешение — BIND_ACCESSIBILITY_SERVICE. В обычных условиях для отображения окон типа TYPE_TOAST, предназначенных для показа системных уведомлений, приложению требуется отправить запрос SYSTEM_ALERT_WINDOW, однако благодаря ошибке в обработчике проверки разрешений Android AOSP вредоносная программа может обойтись без подобных формальностей. Компонент просто не выполняет проверку доступа (permission check) и операции (operation check) при обработке запроса SYSTEM_ALERT_WINDOW для TYPE_TOAST.

В результате использующее уязвимость приложение может безнаказанно рисовать свои окна поверх окон других программ и фиксировать нажатия на экран. Фактически оно получает полный контроль над окном TYPE_TOAST. Какое содержимое будет отображаться в этом окне, зависит только от фантазии вирусописателей.

Cloak and Dagger

CVE: CVE-2017-0752
Уязвимые версии Android: 4.4.4, 5.0.2, 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2
Для эксплуатации требуется: приложение с разрешениями SYSTEM_ALERT_WINDOW и BIND_ACCESSIBILITY_SERVICE
Возможный результат: запись нажатий клавиш (кейлоггинг), утечка данных

Эта уязвимость актуальна для Android вплоть до 7.1.2. Из-за ошибки в SDK вредоносное приложение, используя разрешения SYSTEM_ALERT_WINDOW и BIND_ACCESSIBILITY_SERVICE, может получить практически полный контроль над операционной системой и доступ к конфиденциальной информации пользователя, а также фиксировать нажатия клавиш.

Вкратце суть сводится к тому, что разрешение SYSTEM_ALERT_WINDOW позволяет вывести на экран «системное окно» — View-элемент, который отобразится поверх любого другого элемента интерфейса, даже если это будет Activity из стороннего приложения. При этом перекрытые Activity об этом не узнают и продолжат работать так, как будто ничего и не произошло. Это может сделать любое приложение, если разрешение SYSTEM_ALERT_WINDOW заявлено в его манифесте.

Разместив несколько «невидимых» системных окон друг над другом и обрабатывая нажатия на них, злоумышленник может создать кейлоггер. А с помощью разрешения BIND_ACCESSIBILITY_SERVICE вредоносная программа способна получить доступ к другим объектам ОС и хранящимся на устройстве данным.

Выводы

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

почему не могу удалить выявленные угрозы ?

Фото

  • Members
  • 2 Сообщений:
  • Отправлено 16 Август 2018 — 10:47

    друзья , у меня на телефоне программа обнаружила 3 угрозы

    приложение пишет чтобы их обезвредить , требуется наличие на устройстве root-доступа

    что нужно сделать не пойму

    #2 olenka6710

    olenka6710

  • Members
  • 2 Сообщений:
  • Отправлено 16 Август 2018 — 10:47

    olenka6710, Ольга

    #3 Robiks

  • Posters
  • 53 Сообщений:
  • Отправлено 16 Август 2018 — 17:55

    Если не можете удалить угрозы, значит они встроены прошивку. Удалить их можно только при использовании рут-прав или перепрошивки на кастом. Также можно попробовать файрвол.

    #4 Sergey Bespalov

    Sergey Bespalov

  • Virus Analysts
  • 399 Сообщений:
  • Отправлено 17 Август 2018 — 12:53

    olenka6710, Нужно получить права рут. На разных телефонах работают разные способы получения прав.

    Посмотрите эту тему:

    #5 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 14:20

    Дабы не плодить темы.

    Dr.web обнаружил вирусы:

    Они находятся в разделе «Уязвимости» и не удаляются, при нажатии на название вируса открывается его описание и ссылка на ваш сайт с более подробным описанием вируса ,больше никаких действий сделать нельзя.

    Откатил до заводских настроек, ничего не изменилось.

    Подскажите как удалить вирусы (рут есть)?

    #6 Lvenok

  • Beta Testers
  • 2 643 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 15:06

    Здравствуйте!
    Дабы не плодить темы.
    Dr.web обнаружил вирусы:
    Pendinglntent(CVE-2014-8609)
    Toast Overlay(CVE-2017-0752)
    Janus(CVE-2017-13156)
    Они находятся в разделе «Уязвимости» и не удаляются, при нажатии на название вируса открывается его описание и ссылка на ваш сайт с более подробным описанием вируса ,больше никаких действий сделать нельзя.
    Откатил до заводских настроек, ничего не изменилось.
    Подскажите как удалить вирусы (рут есть)?

    Здравствуйте.
    Это не вирусы, это уязвимости! Они устраняются только установкой обновлении на прошивку. За обновлениями обращаться к производителю устройства.

    #7 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 15:23

    После отката ставил последнюю прошивку

    #8 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 15:38

    Так как устранить уязвимости? Подскажите пожалуйста!

    #9 AndreyKa

  • Posters
  • 923 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 15:42

    Так как устранить уязвимости? Подскажите пожалуйста!

    Если новые прошивки не выпускают, то покупкой нового смартфона.

    #10 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 18:12

    Если новые прошивки не выпускают, то покупкой нового смартфона.

    Сомневаюсь в Вашей компетентности.

    #11 sergeyko

  • Dr.Web Staff
  • 3 925 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 18:16

    Если новые прошивки не выпускают, то покупкой нового смартфона.

    Сомневаюсь в Вашей компетентности.

    И все-таки, против лома нет приема, а кратчайшее расстояние между двумя точками — прямая.

    Либо новые прошивки, либо ой.

    Sergey Komarov
    R&D www.drweb.com

    #12 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 18:24

    Тогда любой новый телефон не застрахован от тех же проблем. И сколько их придётся поменять?

    #13 maxic

    Keep yourself alive

  • Moderators
  • 12 794 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 19:06

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

    #14 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 19:34

    Тело Meizu M3 note, покупал в 16-м году до этого проблем не замечал. Прошивался регулярно по мере выхода прошивок. С месяц назад поймал вирус — стали приходить СМС о платных подписках на разную дрянь. Антивирусом не пользовался, стоял в прошивке родной им и проверялся. Поставил Dr.web, он обнаружил эти уязвимости, СМСки всё равно приходили. Тогда откатился до заводских. Уязвимости остались, СМСки пропали, поставил последнюю прошивку с оф.сайта уязвимости остались.

    #15 Lvenok

  • Beta Testers
  • 2 643 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 19:37

    Тело Meizu M3 note, покупал в 16-м году до этого проблем не замечал. Прошивался регулярно по мере выхода прошивок. С месяц назад поймал вирус — стали приходить СМС о платных подписках на разную дрянь. Антивирусом не пользовался, стоял в прошивке родной им и проверялся. Поставил Dr.web, он обнаружил эти уязвимости, СМСки всё равно приходили. Тогда откатился до заводских. Уязвимости остались, СМСки пропали, поставил последнюю прошивку с оф.сайта уязвимости остались.

    Хмм. 16 год возможно производитель уже «забил» на обновки для него. Напишите производителю что ответят.
    Еще вариант — альтернативные прошивки.

    #16 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 20:01

    Читал 4pda, прошивка моя на данный момент самая актуальная и стабильная. Да и производитель забил. Альтернативы тоже нет. Может ещё раз откатиться

    #17 maxic

    Keep yourself alive

  • Moderators
  • 12 794 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 20:11

    У мейзу с альтернативными прошивками — обычно плохо, Поэтому только кушать то, что дал вендор. И если он не выпускает заплаток для ОС, то и взять их неоткуда. Только смириться.

    #18 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 20:17

    Вообще на сколько опасны эти уязвимости?

    #19 maxic

    Keep yourself alive

  • Moderators
  • 12 794 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 20:20

    saratcyn, опасны. при сочетании условий. Читайте описания к ним. Однако «там, где я ничего не могу — я ничего не хочу». Смысл портить себе нервы из-за того, что изменить нельзя?

    #20 saratcyn

  • Posters
  • 9 Сообщений:
  • Отправлено 12 Сентябрь 2018 — 20:35

    В принципе я особо не переживаю, просто сегодня решил заняться этим вопросом.

    Читают тему: 0

    0 пользователей, 0 гостей, 0 скрытых

    Ответить на цитированные сообщения Очистить

    1. Dr.Web forum
    2. → Русские форумы
    3. → Dr.Web для Android
    4. → Помощь по лечению
    5. Privacy Policy
    6. Terms & Rules ·

    • RSS-лента
    • Сменить тему
      • Doctor Web mobile
      • Doctor Web 7.0
      • Doctor Web 6.0 (classic)
      • Doctor Web 11 (beta)
    • RU
      • EN
      • FR
      • RU
      • DE
    • Отметить все сообщения форума как прочитанные
      • Отметить все как прочитанное
    • Помощь

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *