Tutorials We write a stealer. How to get your hands on Chrome and Firefox passwords.

[RankBit]

The content of the article

• 1. What will the antivirus say?
• 2. Chrome
• 3. Firefox
• 4. Network Security Services (NSS)
• 5. Conclusion

So, browsers based on Chrome or Firefox store usernames and passwords encrypted in a SQLite database. This DBMS is compact and distributed free of charge under a free license. The same as the browsers we are considering: all their code is open and well documented, which will undoubtedly help us.
The example of the styling module, which I will provide in the article, will actively use CRT and other third-party libraries and dependencies, such as sqlite.h. If you want compact code without dependencies, you have to rework it a little, get rid of some functions and tune the compiler properly.

What will the antivirus say?
When advertising their products, virus writers often draw the attention of potential buyers to the fact that at the moment their stealer is not being "fired" by an antivirus.
Here you need to understand that all modern and more or less serious viruses and Trojans have a modular structure, each module in which is responsible for something different: one module collects passwords, the second prevents debugging and emulation, the third determines the fact of working in a virtual machine, the fourth carries out obfuscation of WinAPI calls, the fifth deals with the firewall built into the OS.
So, to judge whether a certain method is "fired" by an antivirus or not, you can only if we are talking about a complete "combat" application, and not by a separate module.

Chrome
Let's start with Chrome. First, let's get a file that stores user accounts and passwords. On Windows, it is located at this address:
Code:

C:\Users\%username%\AppData\Local\Google\Chrome\UserData\Default\Login Data

To perform any manipulations with this file, you need to either kill all browser processes, which will catch your eye, or copy the database file somewhere and then start working with it.

Let's write a function that gets the path to the Chrome password database. As an argument, it will be passed an array of characters with the result of its operation (that is, the array will contain the path to the Chrome password file).

Code:

Please Login or Register to view content

Function call:

Code:

Please Login or Register to view content

Let me explain briefly what is going on here. We write this function straight away with future expansion in mind. One of its arguments is a field browser_family, it will signal the family of browsers we are getting the database from (that is, browsers based on Chrome or Firefox).

If the condition browser_family == 0is met, then we get the browser password database based on Chrome, if browser_family == 1- Firefox. The identifier CHROME_DB_PATHpoints to the Chrome password database. Next, we get the path to the base using the function SHGetFolderPath, passing it a CSIDLvalue as an argument CSIDL_LOCAL_APPDATA, which means:

Code:

#define CSIDL_LOCAL_APPDATA 0x001c // \Local Settings\Applicaiton Data (non roaming)



This feature is SHGetFolderPathdeprecated and Microsoft recommends using it instead SHGetKnownFolderPath. The problem is that support for this feature starts with Windows Vista, so I used its older counterpart to maintain backward compatibility. Here is its prototype:

Code:

Please Login or Register to view content

After that, the function lstrcatcombines the result of the work SHGetFolderPathwith the identifier CHROME_DB_PATH.

The database of passwords has been received, now we are starting to work with it. As I already said, this is a SQLite database, it is convenient to work with it through the SQLite API, which are connected with the sqlite3.h header file. Let's copy the database file so as not to occupy it and interfere with the browser.

Code:

Please Login or Register to view content

Now we connect to the database with the command sqlite3_open_v2. Her prototype:

Code:

Please Login or Register to view content

The first argument is our database; connection information is returned in the second argument, followed by the opening flags, and the fourth argument specifies the operating system interface that this connection to the database should use, in our case it is not needed. If this function works correctly, a value is returned SQLITE_OK, otherwise an error code is returned.
Code:

Please Login or Register to view content

Please Login or Register to view content

Now we begin to directly process the data in the database. To do this, we will use the function sqlite3_exec().

Code:

Please Login or Register to view content

This function has a prototype like this:

Code:

Please Login or Register to view content

The first argument is our password database, the second is the SQL command that pulls out the file URL, login, password and username, the third argument is the callback function that will decrypt the passwords, the fourth is passed to our callback function, but the fifth argument reports an error.

Let's take a closer look at the callback function that decrypts passwords. It will be applied to each row in our query selection SELECT. Its prototype is int (*callback)(void*,int,char**,char**), but we will not need all the arguments, although they must be declared. Let's name the function itself crack_chrome_db, start writing and declaring the necessary variables:

Code:

Please Login or Register to view content

Please Login or Register to view content

And now let's proceed directly to decryption. The Chrome database is encrypted with the Data Protection Application Programming Interface (DPAPI). The essence of this mechanism is that data can only be decrypted under the account under which it was encrypted. In other words, you cannot steal the password database and then decrypt it on your computer. To decrypt the data, we need a function CryptUnprotectData.

Code:

Please Login or Register to view content

After that, we allocate memory and fill the array with passwdsdecrypted data.

Code:

Please Login or Register to view content

Actually, that's all! It passwdswill then contain user accounts and URL. And what to do with this information - display it on the screen or save it to a file and send it somewhere - is up to you.

Firefox
Moving on to Firefox. It will be a little tricky, but we can handle it anyway!

First, let's get the path to the password database. Remember get_browser_pathwe passed a parameter in our generic function browser_family? In the case of Chrome, it was equal to zero, and for Firefox, we set it to 1.
Code:
bool get_browser_path(char * db_loc, int browser_family, const char * location) {
...
if (browser_family == 1) {
memset(db_loc, 0, MAX_PATH);
if (!SUCCEEDED(SHGetFolderPath(NULL, CSIDL_LOCAL_APPDATA, NULL, 0, db_loc))) {
// return 0;
}

In the case of Firefox, we cannot, as in Chrome, immediately specify the path to the user's folder. The point is that the name of the user profile folder is generated randomly. But this is a nonsense obstacle, because we know the beginning of the path ( \\Mozilla\\Firefox\\Profiles\\). It is enough to look for the “folder” object in it and check for the presence of a file in it \\logins.json. "It is in this file that the data of usernames and passwords of interest to us is stored. Of course, in encrypted form. Let's implement all this in code.


Code:

Please Login or Register to view content

At the very end, the variable db_locthat we passed as an argument to our function contains the full path to the file logins.json, and the function returns 1, signaling that it worked correctly.

Now we will get the handle of the password file and allocate memory for the data. To get the handle, we use the function CreateFile, as advised by MSDN.

Code:

Please Login or Register to view content

Everything is ready, but in the case of Firefox, everything will not be as simple as with Chrome - we cannot simply get the data we need with a regular SELECT query, and encryption is not limited to a single WinAPI function.

Network Security Services (NSS)
The Firefox browser actively uses the Network Security Services functions to implement encryption of its base. These functions are located in the dynamic library, which is located at C:\Program Files\Mozilla Firefox\nss3.dll.

We will have to get all the functions we are interested in from this DLL. This can be done in the standard way, with the help of LoadLibrary\GetProcAdress. The code is monotonous and large, so I'll just list the functions we need:

• NSS_Init;
• PL_Base64Decode;
• PK11SDR_Decrypt;
• PK11_Authenticate;
• PK11_GetInternalKeySlot;
• PK11_FreeSlot...

These are functions for initializing the NSS engine and decrypting data. Let's write a decryption function, it's small. I'll add comments to make it clear.

Code:

Please Login or Register to view content

Now all that remains is to parse the logins.json file and apply our decryption function. For the sake of brevity, I'll be using regular expressions and their capabilities in C ++ 11.

Code:

Please Login or Register to view content

Conclusion
We figured out how passwords are stored in different browsers, and learned what to do to extract them. Is it possible to protect against such methods of recovering saved passwords? Yes, sure. If you set a master password in the browser, then it will act as a cryptographic salt to decrypt the password database. It will be impossible to recover the data without her knowledge.[/CODE]

Please Login or Register to view content