Что это https android clients google com auth

android.clients.google.com что это за файл, программа?

Что такое android.clients.google.com? Адрес сервера, файл или программа. Многие пользователи часто ищут такой вопрос на просторах Интернета. В сегодняшней статье мы постараемся понятным языком рассказать что это за сервер и для чего используется. А так же как злоумышленники могут использовать вирусы и зловредные программы под видом хороших приложений.

Что такое android.clients.google.com

Если совсем кратко сервер android.clients.google.com Гугл использует для манипуляций с программами, играми и приложениями на площадке Google Play. Посылая запросы на этот сервер происходят основные манипуляции в Плей Маркете: поиск, информация о приложении для его установки и загрузки, данные об оплате программы(если она платная). Далее формируется ссылка и cookie для загрузки .apk файла. Что бы было понятнее вот основные ссылки для запросов:

• https://android.clients.google.com/appname/search — для поиска приложения по запросу пользователя.
• https://android.clients.google.com/appname/details — тут содержится необходимая информация о приложении необходимая для его загрузки.
• https://android.clients.google.com/appname/purchase данные о покупке и информация о токене для следующего запроса.
• https://android.clients.google.com/appname/delivery — формирование куки и ссылки для загрузки .apk
• https://android.clients.google.com/appname/log — одобрение загрузки — увеличивает так же счетчик скачиваний.
• https://android.clients.google.com/ appname /addReview — добавлениеотзывов и оценка приложения.

Именно по этим адресам злоумышленники собирают, получают и отправляют необходимую информацию. Уже были известны случаи когда в Плей Маркет попадает приложение содержащее троян, а затем устанавливается на пользовательские устройства.
Похожим образом хакеры делают своеобразную копию Play Market для манипуляций и установки опасного софта и поражения смартфонов. Особенно внимательным следует быть пользователям, которые ставили Root права на свое устройство.

Телефоны без рута защищены моделью безопасности самой операционной системы Android, но если на телефоне стоит рут — в файловой системе легко отыскать логины, пароли и токены — всё что необходимо для взлома смартфона.

android.clients.google.com блокирует доступ к Google Play

Если вы заметили что ваше устройство блокирует доступ системы Android к магазину Google Play — вполне вероятно что вы «подхватили» троян или вирусное приложение. Тут всего несколько вариантов решения проблемы:

• Для начала следует убедиться что у вас не включены сторонние VPN программы, сетевые экраны — они могут быть причиной блокировки.
• После просмотрите список последних установленных приложений. Удалите подозрительные и пробуйте запустить Play Market.
• Скачиваем антивирус Касперского или Доктор Веб и сканируем полностью всю систему. Скачать можно с официальных сайтов. Или с площадки «Приложения» если у вас телефон марки Xiaomi.
• Лучшим вариантом будет полная перепрошивка смартфона: полный вайп и сброс всех настроек до заводских. Это поможет если вирус «засел» глубоко. Перед этим кончено же сделайте бэкап контактов, фото и всей нужной информации.
• Если у вас ошибка «не удалось связаться сервером Google» — читайте следующий раздел.

Все действия вы производите на свой страх и риск. Информация представлена исключительно для ознакомления.

Не удалось связаться сервером Google. Повторите попытку позже

Если при попытке зайти в Гугл Плей появляется ошибка: «Не удалась связаться сервером Google. Повторите попытку позже» — это как раз таки манипуляции с поденой IP адреса на «левые» айпи злоумышленников.

Перед тем как читать дальше проверьте время и дату на устройстве — это первая причина почему нет доступа к Гугл Плей.

В файловой система Андроид есть файл hosts. Для его редактирования потребуются рут права и файловый редактор например ES Проводник.

• Запускаем программу ES Проводник.
• Открываем папку System, в ней ищем папку etc.
• Далее находим файл Hosts и выбираем «Редактировать» или править как текст.
• По умолчанию там содержится одна строчка «127.0.0.1 localhost» и пути айпи адреса для работы программ.

Далее ищем строчку с android.clients.google.com. Перед ней нам нужно прописать ее реальный IP адрес — это 173.194.113.129.
Можете проверить это набрав на компьютере «Пуск», «Выполнить», пишем команду cmd.
В консоли пингуем сервер Гугла командой «ping android.clients.google.com».

Таким образом у нас получится строчка 173.194.113.129 android.clients.google.com. Исправляем ее в файле Hosts, сохраняем и пробуем открывать Googple Play.

Заключение

Мы постарались простым языком объяснить для чего нужны сервера android.clients.google.com. А так же как исправить ситуацию если у вас прописаны неверные пути в файле hosts и появляется ошибка «не удалось связаться сервером Google». Напишите в комментариях была ли полезна данная статья, а так же удалось ли исправить ошибки соединения.

Евгений Загорский

IT специалист. Автор информационных статей на тему Андроид смартфонов и IOS смартфонов. Эксперт в области решения проблем с компьютерами и программами: установка, настройка, обзоры, советы по безопасности ваших устройств. В свободное время занимается дизайном и разработкой сайтов.

Источник

Авторизация через Google в Android и проверка токена на сервере

Недавно мне захотелось создать личный проект на андроиде, и основной вопрос был такой: как однозначно идентифицировать пользователя заставляя его делать как можно меньше телодвижений? Конечно же это аккаунт Google. Я пытался пробовать множество примеров в сети — однако API несколько раз обновилось за время своего существования, многие методы не работали, мои вопросы в Google+ по этому поводу либо были вообще никак не восприняты окружением, либо были вроде «Никогда такое не делал».
В этой статье я постараюсь как можно более просто для новичков (вроде меня) описать мой метод авторизации в Google на андроид, получения токена и проверке этого самого токена на сервере.

Небольшая подготовка

Для начала — у вас должны быть установлены Google Play Services в SDK. После их установки можно будет импортировать все необходимые библиотеки. Статья пишется с расчетом на Android Studio — он сам подсказывает, что необходимо импортировать.
У вас должно быть создано активити с кнопкой.
Чтобы было привычнее пользователю можете создать стандартную кнопку Google+ Sing-In
Выглядеть она будет вот так:

Просто добавьте в ваш Layout:

Добавляем действие на кнопку

Пишем в нашем активити:

Собственно присвоим кнопке действие — вызов интенда выбора аккаунта. Если вы работаете в Android Studio он сам вам подскажет, какие библиотеки нужно импортировать, так что это подробно тут я расписывать не буду.
startActivityForResult(intent, 123); — задает код с которым произойдет возврат. 123 это код возврата, он может быть каким угодно. Это необходимо, когда вы делаете несколько интендов, и вам надо обработать их по разному.

Необходимые области доступа

Обьявите эти переменные в классе. Это необходимые нам области доступа. Первый написано в google: «Позволяет определить аутентифицированного пользователя. Для этого при вызове API необходимо указать me вместо идентификатора пользователя Google+. » Второе разрешение нам необходимо для получения личных данных пользователя (Имя, Фамилия, адрес G+ страницы, аватар), и последнее для получения E-mail. Я посчитал это важным, ведь это вполне неизменный идентификатор для записи в бд.

Регистрация нашего приложения.

Изначально забыл этот пункт — исправляюсь.
Нам необходимо зайти на code.google.com/apis/console создать там проект, зайти в Credentials и создать новый Client ID для OAuth выбрав пункт Installed Application -> Android. Там нам необходимо ввести название нашего пакета и SHA1 сумму нашего ключа.
С этим у меня на самом деле было много проблем решил достаточно костыльным способом.
Нашел debug.keystore в %USERPROFILE%\.android\debug.keystore поместил в папку с проектом и прописал в build.grandle:

После чего нам нужно выполнить команду:
keytool -exportcert -alias androiddebugkey -keystore

/.android/debug.keystore -v -list
Сам keytool можно найти в SDK. Из вывода копируем SHA1 в нужное поле.
Как я понимаю метод временный, и для нормальной работы надо создать нормальный ключ. Но для тестирования этого достаточно.

Код получения токена

Где 123 — ваш код, который вы указали ранее, где AcrivityName — название вашего актитивити. Грубо говоря — мы скармливаем функции получения токена необходимые разрешения и имя аккаунта. И заметьте — это все происходит в фоновом режиме, после чего полученный токен передается в написанную мною функцию reg. Она уже отправляет токен и все необходимые данные на сервер.
Так как разрабатываю недавно, с исключениями пока что беда, если есть предложение — напишите в личку или в комментарии.

Проверяем токен на сервере. (PHP)

Хочу обратить внимание, полученный нами токен имеет тип Online. И действует он лишь 10 минут. Для получения offline токена (чтобы дольше работать с ним с сервера) обратитесь к этой инструкции developers.google.com/accounts/docs/CrossClientAuth

Собственно скармливаем токен в googleapis и забираем полученный JSON ответ.

Источник

Обход двухфакторной аутентификации Google

Злоумышленник может обойти двухфакторную аутентификацию (2ФА) на сервисах Google, сбросить пользовательский пароль и получить полный контроль над аккаунтом, просто заполучив т.н. пароль приложения — ПП (ASP — Application-Specific Passwords).

(При всём уважении к рекламной компании Google «Good to Know»)

Злоупотребление паролями приложений Google

2ФА Google предоставляет материал для исследования различных проблем, непременно возникающих в настолько масштабных системах надежной аутентификации.
Чтобы сделать подобную аутентификацию возможной для всех пользователей (и безболезненно интегрировать её в уже существующую экосистему), инженерам Google пришлось пойти на некоторые компромиссы. Такие, например, как пароли приложений.
Несколько месяцев назад мы нашли способ использовать ПП для получения полного контроля над google аккаунтом, полностью обойдя 2ФА. Мы рассказали о нашей находке службе безопасности Google и недавно получили от них ответ, что они предприняли некоторые шаги для нейтрализации наиболее серьезных угроз из тех, что мы обнаружили. И так, вот что мы нашли:

Пароли приложений

Как только вы включите 2ФА, Google попросит вас создать отдельный пароль для каждого приложения, что вы используете (отсюда и название «пароль приложения»), который не поддерживает 2ФА. Этот пароль Вы используете вместо своего основного. Выражаясь конкретнее, вы создаёте ПП для большинства приложений, которые не используют логин из web-формы: e-mail клиенты, использующие IMAP и SMTP (Apple Mail, Thunderbird, и т.п.); XMPP чат-клиенты (Adium, Pidgin и т.п.), а так же различные календари, синхронизирующиеся с помощью CalDAV (iCal, etc.).
Даже некоторые софт от Google вынуждает вас использовать ПП — например, чтобы включить синхронизацию в Chrome или настроить свой аккаунт на Android устройстве. Совсем недавно эти клиенты в большинстве своём перешли на авторизацию через OAuth. В такой модели, когда вы впервые логинитесь на своём новом устройстве или в приложении, вы получаете запрос на авторизацию в web-форме, которая использует 2ФА. После успешной авторизации, сервер возвращает токен с ограниченным доступом, который в дальнейшем используется для аутентификации вашего устройства/приложения.
На самом деле, OAuth токены и ПП очень сильно похожи — в конечном итоге всё заканчивается созданием уникального авторизационного токена для каждого устройства/приложения, которое вы привязываете к вашему google аккаунту. Кроме того, каждый отдельный токен может быть отозван, без ущерба для остальных: если вы потеряли ваш смартфон, вы можете быть уверены, что никто не сможет получить доступ к вашему почтовому ящику, не имея пароля.
И так, основные отличия между OAuth токенами и ПП следующие:

• OAuth токены создаются автоматически, в то время как ПП нужно создавать вручную. Вам нужно пойти в настройки google аккаунта чтобы его создать, а затем скопировать в приложение.
• OAuth токены предоставляют более гибкую модель авторизации и могут быть использованы для ограничения доступа только к определенным данным или сервисам в вашем аккаунте. С другой стороны, пароли приложений, если уж быть совсем точным, не совсем ТОЛЬКО для приложений!

Остановимся на втором пункте подробнее. Если вы создаете ПП для XMPP чат-клиента, этот же самый пароль может быть использован для чтения почты через IMAP или получения списка событий из CalDAV календаря. Что, собственно, не является таким уж сюрпризом. На самом деле, Eric Gorss и Mayank Upadhyay из Google уже указывали на эту слабость в их статье о 2ФА Google:

«Другая слабость ПП в обманчивом впечатлении, что они предоставляют доступ к конкретному приложению, а не полномасштабный доступ к аккаунту»

Authentication at Scale из «IEEE S&P Magazine» vol. 11, no. 1

Получается, ПП могут гораздо, гораздо больше, чем простое получение доступа к вашей почте. На самом деле, они могут быть использованы для аутентификации на большинстве сервисах Google в обход 2ФА!

Авто-логин в Chrome

В последних версиях Android и ChromeOs Google включил в свои браузеры механизм авто-логина в google аккаунты. После того, как вы свяжите ваше устройство с аккаунтом, браузер будет использовать уже существующую авторизацию и перестанет запрашивать её через web-форму. (Есть даже экспериментальная поддержка этой функциональности в десктопной версии Chrome, вы может включить её, открыв «chrome://flags/.»).

До недавнего времени, этот механизм работал даже для самой важной части google аккаунта — странице настроек. Она включает в себя страницу восстановления пароля, на которой возможно добавление и редактирование e-mail адреса и телефонных номеров, на которые вам будет отослана информация, необходимая для сброса пароля. Короче говоря, если вы сможете получить доступ к этой странице — вы сможете отобрать аккаунт у его законного владельца.

Технические детали

В своём отличном блоге Android Explorations Николай Еленков опубликовал обширное исследование механизма авто-логина в Android. Оно стало отличной отправной точкой, но всё не содержала всю необходимую нам информацию. Мы захотели узнать, как можно использовать этот механизм, не имея Android устройства или Хромбука.
Чтобы сделать это, мы установили перехватывающий прокси, чтобы следить за траффиком между эмулятором Android и серверами Google. Во время добавления google аккаунта, мы увидели следующий запрос:

POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&EncryptedPasswd=AFcb4. \
&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17

Ответ, помимо всего прочего, содержал следующее:

Несмотря на то, что урл и некоторые параметры не документированы, это очень напоминает Google ClientLogin API. Чтобы воссоздать такой запрос самим, нам нужно было понять, что за значения нужно передавать в параметрах «EncryptedPasswd» и «androidId». Со вторым всё оказалось просто — это тот самый параметр «ANDROID_ID», упоминаемый в Android API Docs — случайно сгенерированный 64-битное значение, которое предназначено для однозначной идентификации устройства Android.
Другой пост Еленкова вселил нас надежду, что «EncryptedPasswd» может быть нашем ПП, зашифрованным публичным 1024-битным RSA ключём, который включён в Android платформу. «EncryptedPasswd» являлся бинарными данными(закодированными base64) длинной 130 байт, так что вполне возможно, что так оно и есть. Однако, прежде чем двигаться дальше, мы решили попробовать заменить этот параметр параметром «Passwd» (не зашифрованный пароль) из документации и установить ему значение — наш ПП:

POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&add_account=1&Passwd=xxxxxxxxxxxxxxxx\
&service=ac2dm&source=android&androidId=3281f33679ccc6c6&device_country=us&operatorCountry=us&lang=en&sdk_version=17

И это сработало! Мы получили ответ, в котором содержалось что-то очень похожее на валидный токен. Этот токен, созданный сервером android.clients.google.com, стал видим в разделе «Connected Sites, Apps, and Services» нашего аккаунта и, похоже, предоставляет нам полный доступ к аккаунту:

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

POST /auth HTTP/1.1
Host: android.clients.google.com
…
accountType=HOSTED_OR_GOOGLE&Email=user%40domain.com&has_permission=1&Token=1%2Ff1Hu. &\
service=weblogin%3Acontinue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount\
&source=android&androidId=3281f33679ccc6c6&app=com.android.browser&client_sig=61ed377e85d386a8dfee6b864bd85b0bfaa5af81&\
device_country=us&operatorCountry=us&lang=en&sdk_version=17

Этот запрос возвращал тело ответа, а так же следующую строчку:

Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP. &source=AndroidWebLogin
Expiry=0

Из этого запроса мы установили, что форматом для параметра «service» является weblogin:continue=url_encode(destination_url). Мы решили попытаться указать этот параметр для нашего изначального запроса с ПП вместо токена (вместо того, чтобы пытаться понять происхождение непонятного параметра «client_sig»):

POST /auth HTTP/1.1
Host: android.clients.google.com
…
device_country=us&accountType=HOSTED_OR_GOOGLE&androidId=3281f33679ccc6c6Email=user%40domain.com&lang=en&\
service=weblogin%3Acontinue%3Dhttps%253A%2F%2Faccounts.google.com%2FManageAccount&\
source=android&Passwd=xxxxxxxxxxxxxxxx&operatorCountry=us&sdk_version=17&has_permission=1

И получили ответ, полностью повторяющий предыдущий:

Auth=https://accounts.google.com/MergeSession?args=continue%3Dhttps%253A%252F%252Faccounts.google.com%252FManageAccount&uberauth=AP. &source=AndroidWebLogin
Expiry0

Ключевым параметром здесь является «MergeSession». Если вы откроете этот урл в неавторизованном браузере после того, как выполните запрос (это нужно сделать очень быстро), вы будете немедленно залогинены в аккаунт!

Таким образом, имея только имя пользователя, ПП и выполнив запрос к android.clients.google.com/auth, возможно залогиниться на страницу настроек аккаунта, в обход двухступенчатой верификации!

Фикс Google

Как было замечено ранее, этот способ работает даже для самой критичного раздела google аккаунта — настроек. Атакующий может предпринять рад действий, используя ПП жертвы:

• Он может передать «accounts.google.com/b/0/UpdateAccountRecoveryOptions?hl=en&service=oz» в качестве урла в API запросе. MergeSession URL, полученный в ответе, приведёт его прямо на страницу восстановления пароля, где он сможет сбросить основной пароль.
• Аналогично, атакающий может передать в запрос урл «accounts.google.com/b/0/SmsAuthConfig?hl=en», что приведет его на страницу с настройками 2ФА, где он сможет добавлять и удалять ПП или же отключить 2ФА совсем.

Это больше невозможно, начиная с 21 февраля, когда инженеры Google закрыли эту дыру. Насколько мы можем судить, Google теперь поддерживает некое дополнительное состояние, которое позволяет определить, как именно вы аутентифицировались — с помощью MergeSession URL и с помощью обычного логина и пароля, используя 2ФА. Страница настроек станет доступна только в последнем случае. Если же вы залогинились с помощь MergeSession URL, вас перенаправлят на страницу 2ФА, которую нельзя пропустить.

Насколько всё было плохо?

Мы считаем, что это большая дыра в системе аутентификации, если пользователь имеет некую форму для ввода пароля, которая позволит получить доступ к полному контролю над аккаунтом. Но несмотря на это, мы всё же согласны, что даже до того, как Google выкатил свой фикс, включить 2ФА на своём аккаунте гораздо лучше, чем не делать этого.

В наши дни, злоумышленник всё ещё имеет в своём арсенале набор методов для получения контроля над аккаунтом. Например:

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

Оба этих примера представляют собой типы атак, которые могут быть предотвращены с помощью следования простым правилам и «цифровой гигиены». Например, не использовать один и тот же пароль на различных сайтах и не нажимать на подозрительные ссылки в e-mail сообщениях. К сожалению, такого рода «образовательные программы для пользователей» редко работают хорошо на практике(и могут быть нецелесообразны с экономической точки зрения).

Несмотря на это, даже с ПП, 2ФА Google может сгладить оба этих типа атак, даже если пользователи продолжают делать глупые вещи. ПП генерируются Google и не предполагают запоминание пользователем, т.о. маловероятно, что он использует точно такой же пароль на другом сайте. Если даже злоумышленник создаст фишинговый сайт и выманит ПП, его шансы на успех будут значительно (возможно, на порядки) ниже, чем с обычным паролем.

Тем не менее, повсеместное использование ПП всё же несёт в себе потенциальную опасность. Если злоумышленник сможет заставить установить вредоносное ПО, оно сможет найти и извлечь ПП где-нибудь в пользовательской системе (например, популярный чат-клиент Pidgin хранит пароли в открытом виде в XML файле). Кроме того, «толстоклиентские» приложения, основной пользователь ПП, частенько подвержены довольно известной проблеме слабой проверки SSL сертификата, что потенциально позволяет украсть ПП с помощью MiM-атаки.

Фикс Google значительно помогает в данной ситуации. Несмотря на то, что ПП всё ещё могут нанести значительный вред пользователю, он сможет сохранить контроль над своим аккаунтом и возможность отозвать ПП, если вдруг что-то пойдет не так. Тем не менее, мы твердо верим в принцип минимальных привилегий и хотели бы видеть дальнейшие шаги Google, направленные на ограничение привилегий отдельных ПП.

Апдейт #1
Google обновил своё предупреждение при создании ПП, в котором предупреждается о потенциальном риске:

Апдейт #2
Craig Young из nCircle выступил с докладом об аналогичной проблеме на конференции BSides, проводимой совместно с RSA!

Источник