john
john copied to clipboard
openwall
Add RoboForm (AES-256 bit encryption with PBKDF2 SHA-256)
Is it possible to bruteforce Roboform .rfp files ? https://www.roboform.com/
Is it possible to bruteforce Roboform .rfp files ?
No. Anyway, we'll consider this issue as a feature request.
https://hashcat.net/forum/thread-7552.html
@trounce1 This sounds like another fun hack :-). Can team up for this one as well.
C:\Users\USER\AppData\Local\RoboForm\Profiles\Default Profile_settings.rfo
This is the file that is opened when the software opens. it has the email address and a base64 encoded json field of something called "preferences".
The Hashcat forum link has working code. We can start with that.
Also, RoboForm has an Android App. Reversing those .apk files (using jadx for example) is much easier than reversing native code.
ok ive got the app. ill have a peak. i still cant seem to figure out how to create an rfp file. everything is stored in. C:\Users\USER\AppData\Local\RoboForm\Profiles\Default Profile_settings.rfo C:\Users\USER\AppData\Local\RoboForm\Profiles\Default Profile_user-data.rfo C:\Users\USER\AppData\Local\RoboForm\Profiles\Default Profile_app-data.rfo
will install the android app and see what it does
the apk appears to be barely obfuscated and still retains most of the class names
Why do I vaguely remembering working on something similar a long long time back!? I think I gave up because the "verifier" involved is short (2 / 4 bytes).
Maybe it was some similar software with a short verifier, hard to remember now.
I think I gave up because the "verifier" involved is short (2 / 4 bytes).
From Hashcat thread it seems that we could use the "checksum" too as a verifier. Let's see.
FWIW, it was recently researched and widely publicized that RoboForm until "7.9.14 release on June 10, 2015" had a weak password generator, basing passwords on the current time. We could want to implement this as an external mode, separately from us supporting RoboForm files. https://grandideastudio.com/portfolio/security/roboform-password-regeneration/
Also https://x.com/RichDevX/status/1796639662544457850
"reverse engineered the password generation function for anyone that wants to build a brute forcing tool (doesn't require the wrapper/admin privs)"
There's also https://x.com/gat3way/status/1809682038758515076 referring to https://web.archive.org/web/20130621145929/http://www.gat3way.eu/robo for another weakness from 2013, and sample file and code (unfortunately, not saved on the Internet Archive, at least not as part of that date's snapshot):
Cracking RoboForm Lite local databases
Basics
Note: this applies to RoboForm lite on Firefox/Linux. Other versions may or may not use the same implementation.
RoboForm is a popular password manager for Windows/IOS/Android/MacOSX. There is no native linux version, however a browser plugin (RoboForm lite) is available for Firefox and Chrome. There are two modes of operation: online and offline. In the online mode, passwords and other data are stored on the RoboForm cloud servers. In offline mode, the data is stored on the local harddrive. The Linux/Firefox version stores data in ~/Documents/My Roboform Data/. Site logins are saved in the so-called "Passcards"
Each passcard is saved as a separate file with .rfp extension. Together with that, RoboForm maintains a special file, smpenc.rfo, which contains some data related to the master password.
Data files format
rfo files contain UTF16 encoded data which can be either ascii text or binary. Binary sections use another (strange) form of encoding. The idea like with base64 is to have data in printable form. However, no mapping table is used. An example code to decode data (after UTF16 decode) is:
unsigned char c0,c1,c2,c3;
int a,b;
char *encoded;
char *decoded;
int size; // equals the length of encoded data
for (a=0,b=0; a < size; a+=4,b+=3)
{
c0 = encoded[a] - 32;
c1 = encoded[a+1] - 32;
c2 = encoded[a+2] - 32;
c3 = encoded[a+3] - 32;
decoded[b] = ((c0&63)+((c1&3)<<6));
decoded[b+1] = (((c1>>2)&15)+((c2&15)<<4));
decoded[b+2] = (((c2>>4)&3)+((c3&63)<<2));
}
Sections are separated by newlines (\r\n).
smpenc.rfo format
smpenc.rfo contains some service data and part of it is of a particular interest. The format of the file is described below:
The third section is of particular interest, as it provides us means to very quickly validate master password candidates. However, due to DES block size of just 64 bits, it is not capable of validating passwords of length >8 characters. It is used by RoboForm as a quick verifier that can give false positives with longer passwords.
passcard.rfp format
The format of the passcards is described in the diagram below:
The passcard file is not UTF16-encoded, however binary data still uses the "strange" encoding. Binary blobs/text sections are separated by newlines (\r\n). First section is not interesting. Second section identifies the passcard format (as of Firefox/Linux version, the +PROTECTED-2+ one is always used. Third section contains crypto details, DES-encrypted using a hardcoded key. It is of no particular interest to us since AES-CTR encryption is always used. An empty section follows. Then comes the encrypted data, which is again encoded. Any newlines in it should be stripped. Then the encrypted data begins with a header of variable size (depending on master password size).
For passwords of length <32 chars, the header has the following structure:
Salt (8 bytes)
Password Verifier (2 bytes)
Hash (10 bytes)
The encryption and HMAC keys are derived using PBKDF2-HMAC-SHA1 using 1000 iterations, and header salt as salt. 34 bytes need to be derived which means 2000 iterations (total 4004 SHA1 block operations) need to be performed. First 16 derived bytes are the AES-CTR key. Next 16 bytes are the HMAC key and last 2 bytes are the derived verifier. If the derived verifier does not match the header verifier, the master password is declared bad and no further decryption/HMAC is done. That gives 1/65535 probability of false positives at this point.
The encrypted data is then decrypted using AES128 in CTR mode. Note that RoboForm`s implementation is not compatible with the OpenSSL one since RoboForm mixes counter with nonce by arithmetic addition whereas OpenSSL uses XOR. Once data is decrypted, HMAC-SHA1 is calculated on it. First 10 bytes of the HMAC hash are compared to the header hash value. If they match, then we have a correct master password.
Algorithm weakness
We can exploit the verifier from smpenc.rfo to very quickly validate passwords of length <=8. That`s because a single DES ECB operation is rather fast on GPUs (>1000M/s on AMD Radeon HD7970). This means that the alphanumeric keyspace will be bruteforced in about 2 days and a half using 7970.
We can use that to bruteforce even longer passwords, given that the attack against DES verifier discovered a possible master password (first 8 bytes match). That puts us in the same scenario as in Windows LM hashes (with the difference that we do not have the second half of the password DES-encrypted unfortunately).
Thus Roboform is like LM with second part being PBKDF2-SHA1(1000 iterations) rather than simple DES.
Doing 4004 SHA1 block operations on 7970 is as fast as 500K c/s. This means the 6-character alphanumeric keyspace will be bruteforced in about 30 hours. Overall this allows bruteforcing any alphanumeric master password of length <=14 in a matter of 3-4 days using a single 7970. Quite interesting for a password manager :)
Why is this significant? Well, bruteforcing a 14-char alphanumeric password even if hashed with fast, simple algorithm such as MD5 would take about 50 million years on a single 7970. It would take about 4 days to crack the same password if used as a RoboForm master password.
Sample data
Example (poor) code for reading rfp/rfo data: robotest.c
Example smpenc.rfo: smpenc.rfo
Example passcard file: test.rfp