Using BitLocker To Go on Fedora 23 (dislocker)

I have multiple machines, some run Windows and some run Fedora. I also need to keep a significant amount of my data encrypted l, and I need to be able to do this from Windows machines that are not under my control.

Both Windows and Linux have multiple encryption solutions available, with varying levels of uptake and acceptance. However in order to be as compatible as possible for my clients, I decided to use a Windows solution and figure out how to use it on Linux.

BitLocker  is the obvious choice for Windows compatability. Enabling BitLocker on a USB stick, will include the executables required to mount the volume on any Windows machine.

Dislocker can be used on Linux systems to mount the Bitlocker volume – although this tool was initially read only it now supports read/write. (Note I have only tried this using ExFAT formatted drives, however I believe FAT and NTFS will also work.)

The following is my cheat sheet of how to install and use dislocker.

Note: All commands as root

Installing dislocker

Install exfat support

dnf install exfat-utils fuse-exfat

At the moment need to enable the testing repo so that we can get the version of dislocker that supports usb (need at least v0.5) [Could also install from source…]

dnf config-manager --set-enabled updates-testing

Install dislocker

dnf install dislocker fuse-dislocker

Disable the testing repo so that we aren’t getting any other unstable packages when we install

dnf config-manager --set-disabled updates-testing

 

Make a mount point for dislocker container

mkdir /mnt/dislocker-container

Make a mount point for the dislocker file

mkdir /mnt/dislocker

 

Mounting a BitLocker USB device

Find the usb device probably /dev/sdc1 or similar

fdisk -l

Mount the dislocker container (assuming /dev/sdc1 is the USB) using the User password you configured when you setup BitLocker (you will be prompted). Note recovery passwords and filed are also supported.

dislocker -v -V /dev/sdc1 -u -- /mnt/dislocker-container

Make sure that this has worked correctly, ‘dislocker-file’  should be within that directory.

ls /mnt/dislocker-container/dislocker-file

Mount the dislocker-file as a loop device and give everyone permission to write to it (maybe should restrict this more…)

mount -o loop,umask=0,uid=nobody,gid=nobody /mnt/dislocker-container/dislocker-file /mnt/dislocker

Thats it!
Work on the files in /mnt/dislocker you should have read write access (for all users).

Common Errors:

Some error about the /mnt/dislocker-container already existing. You don’t have fuse-dislocker installed so it is trying to create an unencrypted copy of the usb.

Its taking ages and running out of disk space. Same as above, it’s trying to make an unencrypted copy of your volume.

Unmounting

Make sure you aren’t in the directories you need to unmount or it will error

cd /mnt

Unmount the dislocker-file mount point

umount /mnt/dislocker

Unmount the dislocker container mount point

umount /mnt/dislocker-container

Eject the USB device using the file manager on the system.

Done!


As always, if you have any comments or suggestions please feel free to get in touch.

Change the TPM Owner Password and BitLocker Recovery Key

I recently purchased a Microsoft Surface Pro 4 which came with Windows 10. BitLocker was enabled by default during setup, however the recovery key was automatically uploaded to my Microsoft account. While this is a really good feature and for the vast majority of users will not pose a problem, I have slightly different concerns than the average user… therefore I decided I did not want my recovery key to be entrusted to Microsoft.

The quickest and easiest option was to delete the recovery key from my Microsoft account, which can be done here. However although this would remove my ability to get my recovery key from my Microsoft account it gives me absolutely no guarantee that Microsoft actually deleted it in any kind of permanent way, and given that everyone has a rigorous backup process (right? 😉 ), it is actually very likely that they actually still have my recovery key.

To have slightly more confidence I decided to change both the TPM Owner Password and BitLocker Recovery Key on my machine and keep them in a safe place offline in case I ever needed them.

To change the TPM Owner Password, open tpm.msc, then select “Change Owner Password…” in the top right, I followed the prompts within the dialogue box to change the password and save the file to external media.

To change the BitLocker Recovery Key is slightly more involved and utilises  the BitLocker Device Encryption Configuration Tool:

manage-bde

Assuming C: is the BitLocker protected drive you want to change recovery password do the following within an elevated command prompt.

List the recovery passwords:

 manage-bde C: -protectors -get -type RecoveryPassword

Locate which protector you want to change, there is probably only one, and copy its ID field including the curly braces.

Delete this protector:

manage-bde C: -protectors -delete -id [ID you copied]

Create a new protector:

Type manage-bde C: -protectors -add -rp

Note you can specify a 48 digit password at the end of the previous command if you wish, however if one is not specified one is randomly generated for you  – computers are much better at randomly generating passwords than you so probably best to let it do it.

Take heed of the output of the last command:

ACTIONS REQUIRED:

1. Save this numerical recovery password in a secure location away from your computer:

[YOUR RECOVERY KEY IS HERE]

To prevent data loss, save this password immediately. This password helps ensure that you can unlock the encrypted volume.

As always, if you have any comments or suggestions please feel free to get in touch.

Exploiting JSONP

JavaScript Object Notation with Padding (JSONP) is a technique created by web developers to bypass the Same Origin Policy which enforced by browsers to prevent one web application from retrieving information from others. JSONP takes advantage of the fact that in the eyes of the browser not all resources are created equal -JavaScript, images and a few other types can be loaded cross domain.

In order to pass data cross domain JSONP “smuggles” it within JavaScript and utilities a callback. i.e. The receiving domain includes a script tag with the source attribute set to a specific URL of the sending domain. This script from the sending domain contains the data that needs to be sent cross domains and passes it to a function of the receiving domain. The function on the receiving domain will parse data and use it as required.

While this all sounds perfectly innocent, it easily becomes a security vulnerability when you remember that it is often sensitive data that is passed between domains, for example session tokens, and since it is abusing the behavior of the Same Origin Policy there is no built in or standardized security mechanism which may be used to ensure the receiving domain is the intended one.

Depending on the exact usage of JSONP, the vulnerability may result in sensitive information disclosure, Cross Site Scripting, Cross Site Request Forgery, only Reflected File Download. I have most often seen JSONP being used to implement a Single Sign On system, therefore if sufficient validation of the receiving domain is not performed exploitation results in session hijacking or account take over.

In the simplest instance, no validation is performed an exploitation is as simple as including the script from the sending domain within the attacker’s site and persuading a user of the sending application to visit the attacker’s site.

However there are more complex instances where the web developer has attempted to prevent the data being passed to malicious domains. This can take a variety of forms but is often incomplete whether on the client side or the server side.

Anonymous Case Study

On a recent web application test I encountered a single sign on system utilising JSONP and enforcing server side checks on the HTTP Referer header before returning the script containing the session token, and the script itself performed client side checks on the document.domain attribute before passing the token to the JavaScript function. However both of these pieces of validation were flawed and therefore it was possible to hijack the user’s session, and with further work I believe it would have resulted in full account takeover.

The server side validation consisted of a check of the requesting domain against a Regular Expression, however as is often the case the developers overlooked the fact that “.” in Regular Expressions is a wild card. Therefore although the developer only intended to allow “www.somedomain.co.uk” the wild card meant that “wwwXsomedomainXcoXuk” would pass validation (I also identified that any subdomain was allowed i.e “XXXX.wwwXsomedomainXcoXuk”) – however remember it also had to be a valid domain, so the final dot needed to be an actual dot – obviously there were many domains that could be registered to meet these requirements.

The client side validation was significantly more unusual, it consisted of a CRC32 hash of the document.domain and comparing it to a list of approved values. However due to the limited size of the hash (32 bits) it is a mathematical certainty that multiple domains exist that would result in the same hash and therefore pass validation.

In order to exploit this usage of JSONP
I needed to pass both the server and client side validation. To do this I decided to write a Python script to iterate through all the permutations that would pass the Regular Expression in order to identify one that would also pass the CRC32 validation. (Unfortunately this script cannot be released at this time, but I hope to share it in the future as it could be useful to others).

It took over 1.6 billion permutations, but I eventually identified a valid domain and was able register it and exploit the flawed JSONP validation to hijack a user’s session.

Defense

JSONP should no longer be used as HTML5 features like CORS and PostMessage are available with well defined security mechanisms, however these also require careful validation of the “origin” to prevent the data being passed to unauthorised domains.


As always, if you have any comments or suggestions please feel free to get in touch.