Index ¦ Archives ¦ Atom

Two Factor Authentification from Dumped Sqlite Databases

Some of you may be using Google's "Authentificator" app for Android in order to achieve a higher security level for your Google account.

(If you are not yet using it, I recommend setting it up, you can find the details here).

I used to have my web browser set up to always launch in incognito mode (not saving cookies, etc), and as such, Google regularily prompted me for the two-factor authentification token. I did not want to switch to my phone every time, so I decided to reimplement the Google Authentificator as Python script on Windows.

The general algorithm is well known and documented in RFC 6238. There is even a pseudo code implementation available on Wikipedia, so my contribution is the Python implementation featuring simplified usability by reading from an sqlite database.

In order to use the script, you will have to get the "secret" keys from your Android phone to your computer. This is easily possible if you already have root access to your Android phone. In this case, you can use the Android Debugging Bridge (adb) to pull the database from /data/data/com.google.android.apps.authenticator2/databases. An excellent tutorial on how to acquire the database can be found here.

In the end, for other reasons, I decided to switch out of Chrome's incognito mode, so I don't use the authentification script as often as I used to. But I decided to share it anyways:


WinSCP Session Password Decryption - Part 2

After this old article got some more attention recently, I decided to give this subject another shot.

The old C++ code was messy and the result of copying together the right WinSCP source code to create a deobfuscator. This time I decided to implement the same script in Python, adding the feature to read the newest values from this machine's registry, because I am pretty sure that this is the most common use case.

Here it goes:

The usage is much easier this time:

usage: winscp-deobfuscator.py [-h] [--hostname HOSTNAME] [--username USERNAME]
                          [--hash HASH]

Deobfuscate WinSCP password, using info either from registry (if no arguments
are given) or from the command line.

optional arguments:
  -h, --help           show this help message and exit
  --hostname HOSTNAME  HostName
  --username USERNAME  UserName
  --hash HASH          Password

Again: I hope that this will help someone, have fun!

(Fun fact for those of you who are using FileZilla: FileZilla stores the plain-text password in %APPDATA%/FileZilla/sitemanager.xml)


Fixing a Chrome SSL Connection Error caused by COMODO Products

A couple of months ago, I lost my precious Google Chrome browser (running on Windows 7, 64bit): All of the sudden (not so much as I will find out later), Chrome was not able to establish secure connections anymore.

Problem description

The symptoms where a little bit unclear: When I would start the browser, I was able to reach secure sites (with the https:// prefix, port 443) for about 30 seconds. Afterwards, it would always get stuck in the "Establishing secure connection" stage for new connections, until ERR_CONNECTION_TIMED_OUT. The connections that were established in these first moments seemed to work for the rest of the session and usual http traffic (TCP port 80) was not affected.

Researching solutions on the internet yielded a lot of open questions and problems, including obvious solutions as checking firewall settings, reinstalling Chrome, clearing the ssl cache or disabling TLS 1.2 (which is not possible in anymore in current Chrome versions). All of these solutions did nothing for me.

Finding and Resolving the Issue

So, I monitored my network connections with packet capture software (Wireshark). First everything went as expected. But even when the secure connections started to fail, I could clearly see that the handshake completed (SSL Client Hello, Server Hello, Certificate, Client Key Exchange, New Session Ticket), but there was silence after the handshake until Chrome finished and reset the connection 20 seconds later (TCP FIN followed by RST flag). Comparing that behavior to Firefox (which still worked; for comparison, I also enabled TLS 1.2), it was clear that it was Chrome's turn to send data.

The fact that the connections which were established in the first seconds worked for an entire session indicated that some kind of data would be cached, probably certificates. Additionally, because the amount of websites that I could load was not limited by a certain number, but a certain time period, it was quite obvious that my connections were victims of a race condition. So I fired up Sysinternals Process Monitor, filtering only events from the chrome.exe application. After a few tries, the experiment was set up and ready to capture Chrome’s faulty behavior. I started Chrome and navigated to a lot off different web pages, pinpointing the exact time of failure. Using Wireshark and Process Monitor, I found out that at the time of the failure, Chrome just finished reading a lot of certificate files (having to do with different Certificate Authorities and revocation lists). There were especially a lot of accesses to the certificate stores issuers.sst and subjects.sst (located at ... \AppData\LocalLow\COMODO\CertSentry).

Research on the internet showed that these files were remnants of an old COMODO Dragon installation that I got tricked into earlier this year and that had not finished correctly. If one tries to delete them, they are recreated moments after by the DLL certsentry.dll (located at C:\Windows\system32 and C:\Windows\SysWOW64). Using regsvr32 /u certsentry.dll and Unlocker, I was able to unregister and delete the files making a deletion of the certificate stores permanent. After a couple of reboots, Chrome worked again as intended.

But I did not stop here. To further investigate the issue, I kept copies of the DLL files and the certificate lists. Using Dependency Walker, I was able to confirm that there were dependencies on crypt32.dll, cryptnet.dll and cryptui.dll. The certificate stores could be opened with certmgr and included certificates which I had used during my tests (e.g. Google, LastPass, AdBlockPlus, akamai [facebook]). They were still valid though.

Explanation and Conclusion

Earlier this year, I had to manually cancel a COMODO setup procedure and remove all of its remnants. During that procedure, I missed the DLL files certsentry.dll in my system folder which were still being hooked by Microsoft Windows cryptography modules, creating the files issuers.sst and subjects.sst in my user data folder. When Google Chrome is started, the user can immediately start browsing while the certificate stores are loaded. This leads to a race condition. Once all files have finished loading, new SSL connections also fail after completing the handshake. There are a couple things that Chrome and COMODO could learn from these situations: First of all, the asynchronous loading of security files could also be very dangerous since the user does not seem to be protected by the COMODO mechanism in the first seconds. Secondly, there should be a reasonable error message informing the user of SSL errors instead of a time out exception.

For me, I am very satisfied with the result, especially since I have a game jam coming up where I wanted to make use of HTML5 technology, which is faster and more stable in Chrome than it is in Firefox.


Deploying Octopress via SFTP

There were some great tutorials online concerning octopress deployment via rsync or ftp. Unfortunately, my web hosting service only supports access via sftp.

So here it goes:

I wanted to upload my generated html into the directory /octopress of my web host. So modified _config.yml like this:

destination: octopress

and added to Rakefile:

public_dir = "octopress"

## ...

sftp_user = "<user name>"
sftp_target = "<hostname>"
deploy_default = "sftp"

desc "Deploy website via SFTP"
task :sftp do
        puts "## Deploying website via SFTP"
        ok_failed system("echo 'put -r #{public_dir}\n bye' | sftp #{sftp_user}@#{sftp_target}")
end

Now I can just run

rake deploy

and enter my password to upload everything.

ToDo: optimize the mirroring routine so it does not reupload everything everytime


Reversing the WinSCP session password encryption

Edit: this article has been superseeded by a newer version, implemented in Phython: WinSCP session password decryption - Part 2


So today I decided to access my web hosting account via scp from my Linux partition. But of course, I had forgotten my password! So I used the "Offline NT Password & Registry Editor" to extract the necessary settings (from Windows 7 partition):

Open the file

C:\Users\<UserName>\NTUSER.dat

and inside regedit navigate (via "cd") to

\Software\Martin Prikryl\WinSCP 2\Sessions\<SessionName>

From this key, you need the values "Password" (only possible if saved, very long string), "Host" and "UserName".

Finally I reverse engineered the WinSCP source code, which was especially hard because it origins in Delphi, where all strings and arrays are 1-based. My final decrypter code:

Usage (using the values from the registry key):

./decrypter HostName UserName Password

I hope that this will save someone elses time, too!

© Jonas Lieb. Built using Pelican. Theme based on Giulio Fidente's pelican-svbhack.