Installing Older Versions of VeraCrypt on Linux: A Step-by-Step Guide

Introduction:

During some house cleaning I had an old external drive that was encrypted with an old version of truecrypt. I wanted to mount the drive and see what was left on it but the issue was that the latest version of veracrypt isn't backward compatable with the drive. Knowing this, I needed to download the old source code so that I could use the drive. This was done on a ubuntu 22.04.4 LTS. Below are the notes to get it to work on the system. 

Step 1: Download the Older Version of VeraCrypt Begin by visiting the VeraCrypt website (https://veracrypt.fr/code/VeraCrypt/) and navigating to the "Older Versions" section. Here, you'll find a list of previous releases of VeraCrypt. Choose the version you wish to install and download the corresponding package for Linux.

Step 2: Extract the Downloaded Package Once the download is complete, navigate to the directory where the package is saved and extract it using the following command:

tar zxvf VeraCrypt_1.25.4.tar.gz

Replace <veracrypt_package.tar.gz> with the name of the downloaded package.

Step 3: Install Required Dependencies Before installing VeraCrypt, ensure that you have the required dependencies installed on your system. These dependencies may vary depending on your Linux distribution. Common dependencies include gcc, make, libfuse-dev, libwxgtk3.0-gtk3-dev, and libgtk-3-dev. You can install these dependencies using your distribution's package manager. For example, on Ubuntu, you can use the following command:

sudo apt-get install gcc make libfuse-dev libwxgtk3.0-gtk3-dev libgtk-3-dev

sudo apt install -y build-essential yasm pkg-config libwxgtk3.0-gtk3-dev

sudo apt install -y libfuse-dev git libpcsclite-dev  

Step 4: Compile and Install VeraCrypt Navigate to the directory where the VeraCrypt source code was extracted and run the following command to compile and install VeraCrypt:

sudo make sudo make install

This will compile the VeraCrypt source code and install the binary files on your system.

Step 5: Verify the Installation To verify that VeraCrypt has been installed successfully, open a terminal and run the following command:

./veracrypt --version

You should see the version number of the installed VeraCrypt binary printed in the terminal.

Step 6: Launch VeraCrypt You can now launch VeraCrypt by running the following command in the terminal:

./veracrypt

This will open the VeraCrypt graphical user interface, allowing you to create encrypted volumes and manage your encrypted data.

Conclusion: Installing an older version of VeraCrypt on Linux is a straightforward process that ensures you have access to the version of the software that best meets your needs. By following the steps outlined in this guide, you can easily install and use older versions of VeraCrypt on your Linux system, enabling you to secure your sensitive data with confidence.

Sometimes you have to look after yourself (Monitor) #watchyour6

#coding #Monitor #myopinionnotyours

During my day today I was asked about how coding is relevant on a cyber detection team.  This is a good question and pondered on a few of the applications that I have in my own.  Then I decided that the first thing that I usually would do is watch for myself. When you are on a cyber detection team you hopefully have full access to authentication logs and they are stored in a tool that allows for API access.  If you have that capability then the question is "what do I want to monitor but not send to an analyst or detection tool? ... my own authentications.  Why? The short answer is that I am paranoid. I feel that nothing is worse for a cyber defense team than to be part of an incident.

Allow me to frame up a scenario, there is a penetration  in your company and the team decides to leverage internal credentials from known sources. One of those credentials happens to be yours and they decide to use them to auth to server/infrastructure. Now imagine that you didn't even notice. That in my eyes is sort of egg in my face.

The scenerio's can range from internal credential loss or compromise to people trying to leverage your information to gain access. Pick you scenerio but in the end I feel that if you are a victim and are not aware that just plain isn't good.  At my company I have written many scripts and one of them leverages ELK. Using the power of scripting (python) and data (ELK) with an API you would fairly quickly be able to cron out something to watch for authentication for yourself coupled with your own assets adding to a high fidelity alert. Extend that capability using twilio to send alerts and you now have your own alerting framework for yourself that you can extend.

In the the end this is just my option on the matter and just because I am paranoid doesn't mean it's right for you.

Some ideas of leveraging Twilio to extend alerting https://github.com/bl4ck0ut/scripts/blob/master/gmail_twilio_watch_and_text.py

Setting up web based sguil

One of the problems with using Sguil to do network forensics investigations is the client. You need to make sure that your system can support how it runs and it in the end is a think client. The nice thing about OSX is that is has wish installed so getting is running is as simple as running it but the other issue is client hangups etc.  

Recently the author Bamm Visscher updated the code to include a web client on the server. In this post I am going to get it installed on a fresh install of Security Onion. One of the hurdles that you will have is that SO is already running a web server on 443 so we will have to make some modifications. Lets get started. 

First you will need to clone the repo. 

cd /opt/ && git clone https://github.com/bammv/sguil.git 

This will place a fresh install in your opt directory where we will begin. 

Lets stop sguil and do a quick little back up of you current files 

sudo so-sguild-stop && mkdir /opt/sguil_bak && tar zcvf /opt/sguil_bak/lib.bak.tgz /usr/lib/sguild/ && tar zcvf /opt/sguil_bak/sguild.tgz /usr/bin/sguild

Now that we have our back up lets copy our lib files over

sudo rsync -avh /opt/sguil/server/lib/* /usr/lib/sguild/

Ok now lets edit the config. Note change 4433 to whatever port you want to use for the web page.

echo "set HTTPS 1" >> /etc/sguild/sguild.conf 

echo "set HTTPS_PORT 4433" >> /etc/sguild/sguild.conf

echo "set HTML_PATH {/opt/sguil/server/html}" >> /etc/sguild/sguild.conf

Once we have the config in place we need to edit sguild really quick.

sed s/cert.pem/wcert.pem /usr/bin/sguildsed s/privkey.pem/wprivkey.pem /usr/bin/sguild

Last thing before we log into the console we need to generate the keys for the web service 

sudo openssl req -newkey rsa:2048 -new -nodes -x650 -keyout /etc/sguild/certs/wprivkey.pem -out /etc/sguild/certs/wcert.pem

Now that everything is in place go ahead and fire up sguild

sudo so-sguild-start 

You should see everything start ok. When this is done you can open up your browser and head to localhost:4433 or whatever you chose in the previous configs.  You should be presented with your login. This is all the same information that you created while setting up SO.  See below.

After playing with the web client I like the fact that I now no longer have to have a think client and can log in with any device and browser. 

I also wrapped up the above commands into a very simple shell script so that its very easy to get operational.

https://github.com/bl4ck0ut/scripts/blob/master/web_sguil.sh 

Also you can watch the script in action getting sguil web setup.

17 years of linux desktop captures

I know that this isn't a security post but I thought I would take a moment and post some screenshots of the Operating System that I had a passion for many years. I just wish I had my screen shots of the ACID, BASE and Sguil deployments through the years as well

Ever since I switched 100 percent to a linux desktop I would take screen shots just to track the progress of how it evolved. I had been using it since 1998 but it wasn't until 2001 that I was able go all in. In the beginning I had many hurdles, I was building out a large network for the company but they were stuck with Twinaxe cabling and 5250 emulation cards in old 486's. Once I switched the iseries as400 to tcp, then it became how to emulation 5250 which wasn't that bad.

2001 

Getting 5250 emulation working since I was an RPG400 and ILE programmer at the time

December 2001 

Just Playing with more setups pretty sure previous and this was Enlightenment desktop.

Feb 2004

Ximian hits the scene and playing with KDE as my desktop - resolution getting much better

July 2004

Yeah Playing with SUSE again since my first purchase of 6.2 box set in 1999. I bought the box set because I was trying my play my part in growing Linux. 

April 2005

Gentoo - enough said "emerge next-os". Funny you can see my in and outside ids terminals and snort. Only glimps at my deployments.

October 2007 

Pretty sure I was playing with Fedora at the time.

February 2009 

My first Ubuntu build with Gnome. 

May 2011


Multiple screens are just a normal life by this time, Running Ubuntu.

Just a little documented history fun hope you enjoyed the trip. 

Open Source hunting for internal evil

Open Source Hunting for internal evil

Presentation given at mi4n6 meeting on Sept 17, 2014

Feedly OPML file

Slide Deck

Live Linux forensics in a KVM based environment (part 1 memory)

Live Linux forensics in a KVM based environment (part 1)

Most of this blog will be based on a image that I created that I will be walking through. You can obtain this image https://docs.google.com/file/d/0B4pePbirlzGvMjdIblpiV1FjanM/edit?usp=sharing .  You will need to image this to a usb drive preferably a 8gb drive like I used in the talk  To write the image you just need to issue a dd if=./4n6.img of=/dev/your_drive.

Scenerio:
Network team has mentioned they are seeing abnormal traffic to 172.20.20.114 please check out srv03 at 192.168.122.226.

Host system:
OS= ubuntu 12.04 server
user = admin-user
pass = master

Compromised guest:
OS= centos 6.4 64bit
HDD config = 3 disk RAID5 luks encrypted
luks passphrase = mi4n6mi4n6
root pass = master

I will try and write this in a way that will parallel using the techniques on a live virtual instance.

Second, note that the domain that I will be using is srv03. You can replace this value with whatever running domain that you have in your instance.

Memory

One important piece of the incident response puzzle is a memory dump. We know this and obtaining it from a windows machine is fairly trivial. Getting it from a Linux machine also not that hard you just need to have root level access. What about if you have access to a KVM based virtual machine that has several servers running on it? How do you get the memory from the running instances of these systems without having to touch each one of them? Well lets dive in and see. 

First things first, once you have booted the image you will need to run the "srv03_restore.sh" in order to restore the state of the running VM. Once this has completed you will have a running instance of the VM. If you open up xterm you can run the "virt-manager" command and have a visible console on the VM instance.

The quick and dirty

If you have a suspect system and you want to look into what is going on you can just do a dump. This will essentially dump the used memory of the running server. One caveat is that it will temporarily pause the running OS.While it dumps the memory. The nice thing is that it will only dump the used memory, but that can be bad as well since we could miss something, but alas this is quick and dirty. So lets get to it.

You can dump using "virsh dump svr03 ./mem.dump"

now that we have this we can start our investigation. The fast way is just using strings and grep. Since we know were to start traffic to 172.20.20.114 we can grep for that.  "sudo strings mem.dump | grep 172 | less"

with a little searching in the less we come across this:

This is interesting I would say. Something has opened a reverse shell to the suspected ip address. Since I want to be thorough I keep looking and then I find this later in the memory:

Hmm what is this matahari.py and what is it doing the uploads directory? A quick search lends to the knowledge that it is a simple command and control system. This command is showing that that is checking in with the server at 172.20.20.114 . Ok, I think at this point we can say the system is compromised. I am not going to dive into this just yet since I want to show another way that we can access the memory of the system since we have the nice feature of being virtual.

Memory for Volatility

Since we talked the quick and dirty lets get a little more elegant. Let's say that we want full memory in a format that we can use such awesome tools as volatility. How can we do this? With libvmi of course. http://code.google.com/p/vmitools/ . This tool ends up being perfect for what we are looking for.

You will first need to install the tool which has a perfectly good readme that will tell you how to install. For those that cannot wait its just as simple as

autogen.sh
./configure
make
sudo make install

The tool that we are going to talk about is pyvmifs.py . In order to use this tool you will also need to install it. It will be located in the libvmi/tools/pyvmi directory. The installation is also strait forward with "python setup.py build" and "python setup.py install" . This will get you up and running. As a side note there are package dependencies they are met with the build that you downloaded.

Now that we have it installed we can actually mount the memory in a format that we can read with volatility. You can mount it like this. "sudo python ./pyvmifs.py -o domain=srv03 /path/youwant/to/mount/"  and you should see a file names "mem" the size of the memory that is allocated for that virtual instance.

Now we have the mounted memory we can do what we want with it. Strings and grep or use volatility. Let's go the volatility route since we already went the strings grep way. To do this you will need to have a profile for the running linux instance that include the dwarf file and the symbols from boot. Here is the profile for a default centos 6.4 64bit.

http://dl.dropbox.com/u/12565646/cent64.zip

This profile I placed in the volatility directory on the image. If you downloaded the image and are using it there is no need to download again.

One interesting command that requires a little extra information that I want to run first is the "linux_bash" command. This command requires the use of a value that you can obtain by disassembling the /bin/bash binary history_list. You can obtain the value from a previous post but I will also include it here.  Let's run the command and see what we can get from it.

"sudo python vol.py --profile=Linuxcent64x64 -f /media/g/mem linux_bash -H 0x6e0970 -P"

You can see that this gives some interesting information but doesn't show the host that we want. You can see that some one has used "nc" to 192.168.122.129. This is interesting but not what we are looking for. Let's try another command such as netstat.

Great this gives us what we are looking for further confirmation. Let's try another command just for fun linux_psaux.

"sudo python vol.py --profile=Linuxcent67x64 -f /media/g/mem linux_psaux"

Ok, now we have more information.  We can now proceed and get the forensic disk image and see what this matahari.py is.

In conclusion we now have 2 ways to obtain memory from a virtual instance. I also talked about a few ways to deal with this memory. How you choose to go forward with this will be your choice. Hopefully this gives you the chance to experiment and play with these ways on a running system. 

Part 2 will entail how to use the images and mount the luks encrypted raid 5 guest OS .

Linux bash history_list info for volatility

Starting Linux analysis with volatility

When working in the security field you will eventually come across a time that you will need to do some memory analysis. This analysis will entail working with volatility for memory forensics. Most of the time you will end up working with windows systems that may have been compromised. When you are working against a Linux memory dump you will need a few extra things to make this possible.

linux_bash

The linux_bash option within volatility requires you to to know the history_list location so that you can scrape the bash history out of memory. The way that you would do this would be to use gdb and disassemble the history_list and in the comments you will note the information that you will need. I will include a few of them on this page. I don't want to include too many since they are trying to create a way to determine the value on the fly but I cannot confirm the status of that. Here are a few values that I quickly gdb grabbed out that might help others as well. I will include more if people find it to be beneficial to have a single location. A well documented way to obtain the values are located on the volatility site http://code.google.com/p/volatility/wiki/LinuxCommandReference23#linux_bash


Centos
6.4  - 0x6e0970 - bash-4.1.2-14.el6.x86_64.rpm
6.3 -  0x6e0950 - bash-4.1.2-9.el6_2.x86_64.rpm
6.2 -  0x6e0910 - bash-4.1.2-8.el6.centos.x86_64.rpm
6.1 -  0x6e0910 - bash-4.1.2-8.el6.centos.x86_64.rpm
6.0 -  0x6e1af0 -  bash-4.1.2-3.el6.x86_64.rpm
5.9 -  0x6bf970 -  bash-3.2-32.el5.x86_64.rpm
5.8 -  0x6bf970 -  bash-3.2-32.el5.x86_64.rpm
5.7 -  0x6bf970 -  bash-3.2-32.el5.x86_64.rpm
5.6 -  0x6bf970 -  bash-3.2-24.el5.x86_64.rpm

Ubuntu
11.04 - 0x6ed3a8


This probably gives an idea of what I will talk about next ...linux profiles.  I will create a profile for all of the above systems and provide them on the next post. This post will also be updated until the disassemble piece in 2.3 happens.

References:

http://code.google.com/p/volatility/