Elcomsoft Cloud Explorer: новый подход к авторизации в Google Account

15 июня, 2017, Oleg Afonin
Рубрика: «Новость Элкомсофт», «Разное»
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Даже если вы следите за новинками нашей компании, вы могли пропустить информацию об обновлении Elcomsoft Cloud Explorer, криминалистического инструментария для извлечения данных пользователей из учётных записей Google Account. Минорное изменение номера версии (1.30 > 1.31) предполагает обычный список, состоящий из мелких исправлений и улучшений производительности. В данном случае это совсем не так.

В Elcomsoft Cloud Explorer вошёл совершенно новый механизм авторизации в учётные записи Google Account. Принципиальная разница между новой и старой схемами авторизации в том, что новый механизм позволяет нашей программе представиться смартфоном, а не веб-браузером. В чём плюсы и минусы такого подхода, почему возникла необходимость в новом механизме авторизации и почему мы выпустили  его именно сейчас – в этой статье.

Изначально Elcomsoft Cloud Explorer 1.31 планировался как минорный релиз, содержащий те самые не стоящие упоминания мелкие исправления и улучшения производительности. Параллельно в компании разрабатывался новый механизм авторизации в Google Account, который планировалось представить в следующем крупном обновлении. Однако реальность внесла свои коррективы. Несколько дней назад Google внёс ряд изменений в механизмы авторизации для веб-браузеров. Elcomsoft Cloud Explorer, представлявшийся в качестве веб-браузера, перестал работать. В то же время, изменения ничуть не повлияли на авторизацию парка смартфонов под управлением Android. Здесь и пригодился новый механизм авторизации, основанный на протоколах, использующихся телефонами (а не браузерами). Он стал заметно надёжнее и устойчивее к будущим изменениям.

Как это работает

Авторизация в облаке обобщенно состоит из двух шагов:

  1. Получение на базе логина и пароля refresh token
  2. Обмен refresh token на access token

Refresh token – это маркер, который нужен для того, чтобы единовременно пройти авторизацию в «облаке», и на его базе запросить access token для доступа к разным категориям данных.

Access token – это маркер, который нужен для доступа к конкретной категории данных (Hangouts, Wi-Fi, данные Chrome, Dashboard, Location и так далее.)

Изменения, которые реализованы в ECX 1.31 в ходе имплементации device-approach, затронули только шаг 1. Шаг 2 остался неизменным.

Как это было

В предыдущих версиях продукта Elcomsoft Cloud Explorer представлялся в качестве веб-браузера. Для шага 1 (получения refresh token) ECX осуществлял авторизацию на базе логина и пароля (а также одноразового кода, если была включена двухфакторная аутентификация). Далее запрашивались cookie, после чего cookie обменивались на refresh token.

По сути, это — эмулирование поведения браузера. Именно такая авторизация использовалась для доступа к данным из всех категорий, кроме Wi-Fi и Calls. Для Wi-Fi и Calls мы использовали запросы Android устройства; к сожалению, этот алгоритм невозможно было масштабировать на извлечение других категорий.

Серьёзной проблемой данной схемы авторизации было ограниченное время жизни первичных cookie. Со временем срок их действия истекал; соответственно, полученный на их базе token не был долгоживущим.

Новый механизм авторизации

Для реализации нового механизма авторизации были восстановлены и реализованы запросы к Google для получения refresh token. Эти запросы эмулируют устройство, в них не участвуют cookie. Из-за исключения из механизма короткоживущих cookie для получения маркера, новый refresh token – долгоживущий. Его имеет смысл сохранять для последующего использования с целью повторного входа в учётную запись.

Подчеркнем, что дальше, уже на этапе скачивания данных, cookie всё-таки запрашиваются; конкретно — для доступа к категориям Chats (Hangouts) и History. Разница со старым механизмом в том, что на базе refresh token, полученного старым механизмом, мы не можем получить эти cookie, а на базе маркера, полученного новым способом, — можем.

Одним из плюсов нового подхода к авторизации стала возможность сохранения и повторного использования данных авторизации: теперь при успешном логине сохраняется токен (маркер аутентификации). Все последующие сессии автоматически авторизуются с помощью маркера; необходимости повторного ввода логина, пароля и одноразового кода 2FA нет. Подобный подход давно используется в другом продукте компании, Elcomsoft Phone Breaker.

Есть у нового подхода и недостатки. Главный минус: теперь при первом входе в аккаунт (по паролю) владельцу учётной записи придёт уведомление от Google на почтовый ящик. При повторном входе с маркером уведомление не приходит. Связано это с изменениями в поле user-agent в новой версии ECX. Старые версии (1.30 и более ранние) представлялись веб-браузером и использовали самые разнообразные строки в поле user-agent для доступа к разным типам данных. При этом сами запросы формировались способом, который использовался при доступе через браузер.

В ранних версиях ECX использовались следующие поля:

  1. Для авторизации в аккаунт и для скачивания данных Chrome использовался user-agent: “User-Agent: Chrome WIN0.2183.0 (679d31a211c8844eda3ec6b51efadb54e8fe1d0b-refs/heads/master@{#298759})-devel”
  2. Для скачивания данных Dashboards и Hangouts: “User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36»
  3. Для скачивания Wi-Fi и Calls: “User-Agent: GoogleAuth/1.4 (sailfish NOF26V) и  GoogleAuth/1.4 (hammerhead MPZ79M)”
  4. Так называемый “device approach” для Locations (а именно – для доступа к подкатегориям Places и Routes): “User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0; Nexus 5 Build/MPA44I”

В новой сборке Elcomsoft Cloud Explorer мы ушли от использования механизма для браузера. Теперь все запросы формируются в унифицированном формате, который используют устройства под управлением Android. В качестве user-agent теперь передаётся следующая строка:

User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Сам по себе новый метод аутентификации не приводит к дополнительным уведомлениям пользователя. Уведомление пользователь получает тогда, когда Google видит попытку входа в учётную запись с «нового» устройства. В связи с изменением поля user-agent ECX 1.31 и будет являться таким «новым» устройством в сравнении с ECX 1.30 и более старыми, что и приводит к отправке пользователю уведомления.

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

Не обошлось и без пресловутых «исправлений и улучшений». В новой версии Android O Developer Preview на устройствах Google Pixel перестало работать скачивание текстовых сообщений SMS. Эта проблема также исправлена в текущей версии ECX.


  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
НАШИ НОВОСТИ