GNU/Linux

Cannot update Kali Linux due to invalid signatures 4

 in GNU/Linux  tagged invalid / kali / signatures / update by

We have this Kali live USB for a few months and it was not used in between. Yesterday, we tried to use it and noticed that we could not perform any updates as we were getting the following error:

The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>

The same stick was used in the past to create a native installation on a PC that had the same issue (because it was also not used for some time).

To fix the issue we had to get a fresh copy of the archive key for Kali repositories and import it into apt.
To do so, our one line solution was the following:


wget -q -O - https://archive.kali.org/archive-key.asc | apt-key add;

To breakdown what the command is all about: we used wget, which is a non-interactive network retriever, to download the PGP public key for the Kali archives. Instead of saving the key as a file to the filesystem, we used the parameters -q and -O so that wget would be quiet and not create any output of its own and print the key on the terminal (using -O). Then we piped the key to apt-key add to add it to the system. After doing so, we were able to properly update the complete system using the following commands:


apt-get update && apt-get upgrade && apt-get dist-upgrade;

Below you will find our console logs:

root@kali:~# apt-get update && apt-get upgrade && apt-get dist-upgrade
Get:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease [30.5 kB]
Err:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease
The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
Fetched 30.5 kB in 2s (10.5 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease: The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
W: Failed to fetch http://http.kali.org/kali/dists/kali-rolling/InRelease The following signatures were invalid: EXPKEYSIG ED444FF07D8D0BF6 Kali Linux Repository <[email protected]>
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

root@kali:~# wget -q -O - https://archive.kali.org/archive-key.asc | apt-key add
OK

root@kali:~# apt-get update && apt-get upgrade && apt-get dist-upgrade
Get:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease [30.5 kB]
Get:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages [16.2 MB]
Get:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages [16.2 MB] 
Get:3 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/non-free amd64 Packages [166 kB] 
Get:4 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/contrib amd64 Packages [99.0 kB] 
Fetched 451 kB in 1min 6s (6790 B/s) 
Reading package lists... Done
Reading package lists... Done
Building dependency tree 
Reading state information... Done
Calculating upgrade... Done

Change date in GoPro media (photos/video/low quality videos/still frames) files 2

 in GNU/Linux  tagged date / EXIF / exiftool / GoPro / metadata by

Recently, we took some videos and pictures with our GoPro camera which was not used for some time and discharged. Due to that, the date and time configuration of the camera was wrong and the resulting video files had wrong metadata information in their EXIF.

To update the dates in the produced video and photo files we used the exiftool that is shipped in the perl-Image-ExifTool package.
We usually use Fedora, so we used dnf to install the application with all needed dependencies as follows:


sudo dnf install -y perl-Image-ExifTool;

After installing exiftool, we used the following script to change the dates and times of the media files using an offset between the camera date and the real date:

[download id=”4544″]

#!/bin/bash

directory="$1";
echo "Processing '$directory'";
date_change="$2";
echo "Change '$date_change'";

find "$directory" \( -iname "*.mp4" -o -iname "*.lrv" -o -iname "*.jpg" -o -iname "*.thm" \) -type f -execdir sh -c '
	image=$1;
	echo "$image ";
	old_date=`exiftool -d "%a %b %d %T %Z %Y" -CreateDate -S -s "$image"`;
	echo -e "\t$old_date";
	new_date=`date -d "$old_date $date_change"`;
	echo -e "\t$new_date";
	formated_date=`date "+%Y:%m:%d %H:%M:%S %Z" -d "$new_date"`;
	echo -e "\t$formated_date";
	exiftool "-AllDates=$formated_date" "-TrackCreateDate=$formated_date" "-TrackModifyDate=$formated_date" "-MediaCreateDate=$formated_date" "-MediaModifyDate=$formated_date" -overwrite_original "$image";
' _ '{}' \;

[download id=”4544″]

Usage Example:

After we extracted the script to a folder we were able to use it as follows:


./mediaDates.sh '/run/media/100GOPRO' '+ 3 years + 6 months + 11 days + 7 hours + 5 minutes';

Notes:

  • You need extra disk space to update the file as it creates a copy of it even if you overwrite the original
  • If you skip -overwrite_original, then a new file will be created
  • We had to update several date fields in order to be sure that we covered all of them that were visible in the EXIF data of the media

Link to an older post that handles a single video each time.

GNU/Linux: How to give access to a subfolder to a user where the user does not have execute permission over the parent folder

 in GNU/Linux  tagged bind / execute / GNU/Linux / mount / symlink by

On GNU/Linux, you can traverse a directory if and only if you have execute permission on the whole path that you are going to use to access it. This rule applies a limitation to scenarios where for some reason you want to give execute access to a certain user on a subfolder but you do not want to enable the execute permission on the all the folders in the path.

In order to access the folder theFolder in the path /folderA/folderB/theFolder, if you are on the same level as folderA (or higher) you need to have execute permission both on folderA and folderA/folderB additionally to the permissions needed on theFolder. On another scenario if you are located in the same level as folderB (and you have execute rights to it) even if you do not have the execute rights to folder folderA you would still be able to access theFolder as your whole path (which is a relative path in this scenario) skips folderA. This feature is due to the fact that in GNU/Linux that the path that you use to access a folder determines your access constraints. In cases where the user does not have execute access to the whole path, creating symbolic links for them will not help you give them access. The kernel will still go through the access rights of the whole path that the symlink describes and it will act accordingly.

A hack-ish solution around this issue is to use mount to remount a part of the file hierarchy somewhere else using the bind parameter. For example: if we needed to give access to a user to the folder theFolder that resides in /folderA/folderB/theFolder without enabling execute rights on folderA nor /folderA/folderB we could execute the following command in a folder where that user already has execute access in (for example in the user’s home folder).


sudo mount --bind /folderA/folderB/theFolder finallyTheFolder;

Notes:

  • This solution circumvents security, be sure to think things through before implementing it
  • This solution ‘escapes’ normal good practices so it could lead to software bugs on your behalf
  • The bind will not persist after a reboot
  • To make this change permanent, you will need to add a configuration line in /etc/fstab
  • If the directory that you wish to bind contains mounted file systems, these file systems will not be transferred to the target. The mount points will appear as empty directories.

Using TeamViewer tar package on Ubuntu

 in GNU/Linux  tagged teamviewer / ubuntu by

Recently, we needed to start TeamViewer on an Ubuntu GNU/Linux machine where we did not want to install it.
To do so, we used the 64bit tar package from the TeamViewer Linux download page.

After downloading the package and extracting its content, we realised that we could not start TeamViewer (./teamviewer) as is.
In order to troubleshoot, we used a terminal and executed the check libraries functionality (./tv-setup checklibs;) from the archive folder that gave us some missing dependencies:

./tv-setup checklibs

    -=-   TeamViewer tar.xz check   -=-     

  In order to use the tar.xz version of TeamViewer,
  you have to make sure that the necessary libraries are installed.

    Writing raw output to /home/xeirwn/Downloads/teamviewer_13.1.3026_amd64/teamviewer/logfiles/DependencyCheck.log

 Analyzing dependencies ...           
    libQt5Core.so.5 => not found
    libQt5DBus.so.5 => not found
    libQt5Gui.so.5 => not found
    libQt5Network.so.5 => not found
    libQt5Qml.so.5 => not found
    libQt5Quick.so.5 => not found
    libQt5WebKit.so.5 => not found
    libQt5WebKitWidgets.so.5 => not found
    libQt5Widgets.so.5 => not found
    libQt5X11Extras.so.5 => not found

    The libraries listed above seem to be missing.
    Please find and install the corresponding packages.
    Then, run this command again.

    QtQuickControls seems to be missing

    The following command may be helpful:
      apt-get install libdbus-1-3 libqt5gui5 libqt5widgets5 libqt5qml5 libqt5quick5 libqt5webkit5 libqt5x11extras5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-window2 qml-module-qtquick-layouts;

Solution: Following the instructions we executed the following:

sudo apt-get install libdbus-1-3 libqt5gui5 libqt5widgets5 libqt5qml5 libqt5quick5 libqt5webkit5 libqt5x11extras5 qml-module-qtquick2 qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-window2 qml-module-qtquick-layouts;

After the installation of the libraries, we executed once more the check libraries functionality (./tv-setup checklibs;)  where we got the message that everything seem to be OK.

 ./tv-setup checklibs

    -=-   TeamViewer tar.xz check   -=-     

  In order to use the tar.xz version of TeamViewer,
  you have to make sure that the necessary libraries are installed.

    Writing raw output to /home/xeirwn/Downloads/teamviewer_13.1.3026_amd64/teamviewer/logfiles/DependencyCheck.log

 Analyzing dependencies ...           

    All library dependencies (*.so) seem to be satisfied!

    QtQuickControls seems to be installed

Trying to start the (./teamviewer)  application did not gave an error but it would not start again.
It appeared that there was a service running which would not allow the GUI to show up.
To avoid too much fuss, we restarted the machine and tried (./teamviewer)  once more, this time with success.
So after installing the libraries and restarting the machine, we were able to start TeamViewer on our Ubuntu machine without installing it.