Hacking Exposed Computer Forensics Blog

Showing posts with label linux. Show all posts

Daily Blog #784: Validating linux systems with Yum

Hello Reader,

In the prior posts I've been posting about using rpm to validate packages, but there are other package managers out there. I've decided to look into each package manager individually and then maybe we can make a conditional script to handle all of them. Here is the yum version:

#!/bin/bash

# Files to store results
VERIFIED="verified"
FAILURES="failures"
DEBUG="debug"

# Clean previous results
> "$VERIFIED"
> "$FAILURES"
> "$DEBUG"

# Iterate over installed packages managed by yum
for package in $(yum list installed | awk 'NR>1 {print $1}' | cut -d. -f1); do
echo "Processing package: $package"

# Find repository URL
repo_url=$(yumdownloader --urls "$package" 2>/dev/null | head -n 1)

if [[ -z "$repo_url" ]]; then
    echo "Repository URL not found for package: $package" | tee -a "$FAILURES"
    echo "$repo_url $package" | tee -a "$DEBUG"
    continue
fi

# Download RPM package temporarily
tmp_rpm="/tmp/${package}.rpm"
curl -s -L "$repo_url" -o "$tmp_rpm"

if [[ ! -f "$tmp_rpm" ]]; then
    echo "Failed to download RPM - Package: $package" | tee -a "$FAILURES"
    echo "$repo_url $package" | tee -a "$DEBUG"
    continue
fi

# Get repository file hashes from the downloaded RPM
repoquery_hashes=$(rpm2cpio "$tmp_rpm" | cpio -idmv --no-absolute-filenames 2>/dev/null; find . -type f -exec sha256sum {} \;)

# Verify files
echo "$repoquery_hashes" | while read -r repo_hash repo_file; do
    local_file="/$repo_file"

    # Check file existence and type
    if [[ ! -x "$local_file" ]] || [[ ! -f "$local_file" ]] || [[ -h "$local_file" ]]; then
      continue
    fi

    # Calculate local disk hash
    disk_hash=$(sha256sum "$local_file" 2>/dev/null | awk '{print $1}')

    if [[ "$disk_hash" == "$repo_hash" ]]; then
      echo "Verified - Package: $package, File: $local_file" >> "$VERIFIED"
    else
      echo "Hash mismatch (Repository) - Package: $package, File: $local_file" | tee -a "$FAILURES"
      echo "$disk_hash $repo_hash $package $local_file" | tee -a "$DEBUG"
    fi
done

# Cleanup extracted files and downloaded RPM
rm -rf ./* "$tmp_rpm"
done

echo "Verification complete. Results are stored in '$VERIFIED' and '$FAILURES'."

Daily Blog #780: Self validating linux executables

Hello Reader,

When I first started doing Digital Forensics and Incident Response (DFIR) back in 2000, one challenge I faced was verifying the integrity of Linux executables. Often, systems didn't record file hashes during installation, and sometimes we didn't even have a reliable set of installation media to compare against.

To solve this problem, I initially wrote a lengthy Perl script. The script went through each installed package on the local system, comparing the file hashes on disk against the original package hashes, and then validating these against the official distribution hashes.

Today, this task is much simpler. On Linux systems using RPM (like RedHat, Fedora, or CentOS), you can quickly verify a file's integrity with a single command:

rpm -Vf /path/to/file

What does this command do?

rpm -V (or rpm --verify) checks the integrity of installed packages.
-f identifies the installed package that owns the specified file and then verifies the file against the original installed version.

Example Output:

Running the command might give you output like this:

S.5....T.  c /etc/httpd/conf/httpd.conf

Here's what those verification flags mean:

Flag	Meaning
S	File size differs
M	Mode (permissions) differs
5	MD5 checksum differs
D	Device number mismatch
L	Symlink path differs
U	User ownership differs
G	Group ownership differs
T	Modification time differs
P	Capabilities differ
.	Test passed (no changes)

If the command produces no output, the file exactly matches what's included in the installed RPM package.

Quick Example:

rpm -Vf /usr/bin/bash

This command verifies the integrity of the bash executable against the installed bash RPM package.

Also Read: Daily Blog #779: Sunday Funday 3/16/25

sunday funday

Daily Blog: #699: Sunday Funday 5/10/20 - Auditd Challenge

Hello Reader.

We've bounced from Windows to OSX and around the cloud. What we haven't done though is venture in the deep waters of Linux forensics. Today let's help out our fellow examiners who are in the trenches with few landmarks to lead their way in the linux forensics wasteland with this weeks challenge focused on Auditd.

The Prize:

$100 Amazon Giftcard
An apperance on the following week's Forensic Lunch!

The Rules:

You must post your answer before Friday 5/15/20 7PM CST (GMT -5)
The most complete answer wins
You are allowed to edit your answer after posting
If two answers are too similar for one to win, the one with the earlier posting time wins
Be specific and be thoughtful
Anonymous entries are allowed, please email them to dlcowen@gmail.com. Please state in your email if you would like to be anonymous or not if you win.
In order for an anonymous winner to receive a prize they must give their name to me, but i will not release it in a blog post

The Challenge:

On a Linux system with Auditd enabled answer the following quesitons:

1. What new data sources does Auditd create

2. What tools support the data

3. What can an examiner determine from Auditd

4. How long is the data retained for

Also Read: Daily Blog #698

write cache

Daily Blog #682: Linux Kernel Patches for Safe Forensic Imaging

Hello Reader,
Are you using Linux as your DFIR environment of choice? Many are and for good reason. Linux makes many things easy thanks to the wide variety of open source DFIR tools available, premade distributions (SIFT, Paladin, DEFT, etc...) and the ability to quickly turn evidence into mountable file systems.

However for all the good there are some Linux internals that might be silently tripping you up. The first is something a lot of us have known for awhile. If you mount a journaled file system that Linux supports (ext3/ext4 are good examples) the underlying driver may replay the journal even if you tell it read only.

In addition to this Maxim Suhanov (@errno_fail) is now showing that write blockers that make a device appear to be writeable and actively suppress errors to make the device appear to be working can lead to a different set of issues. In this case the in memory cache will replay the journal and record other changes unless you pass into dd the direct iflag value to tell to skip the write cache in memory and look at the disk itself. This was a new one to me and very interesting. In fact I initially thought this was something the write blocker was doing wrong and asked for the firmware revision only to realize when thinking about it again that the issue is with the write cache itself.

The write cache is not unique to Linux, all modern operating systems do it. But I didn't think to find a way to bypass when disk imaging and I'm glad Maxim brought it up. Maxim documented this in his Github project for his Linux write blocker kernel module:

In-memory modifications

Some changes to a mounted file system made by a file system driver can be cached in memory, although they won't reach a physical drive (with the patch enabled and a block device marked as read-only, of course). In this situation, reading a "modified" data block with a userspace program (e.g. dd or md5sum) will result in inconsistency between data received by a userspace program and data actually stored on a drive, i.e. a userspace program will get the bytes from cache (containing modifications from a driver), not from a drive (no modifications here). Unmounting a file system will bring things back to normal.

If you want to make sure your Linux kernel is really treating a disk read only you can use Maxim's kernel model: https://github.com/msuhanov/Linux-write-blocker#in-memory-modifications

If you want to read the original tweets go here: https://twitter.com/errno_fail/status/1253363615282991105?s=20

Daily Blog #255: RHEL Forensics Part 4: More on mlocate.db

RHEL Forensics Part 4: More on mlocate.db by David Cowen

Hello Reader,
Today we have something special, a guest post from Hal Pomeranz. One of the best parts of sharing research and information is when others come back and extend their work for the benefit of us all. Today Hal Pomeranz has kindly not only shared back his work in extending the idea of recovering mlocate database's from unallocated space, he's written a tool to do so! I'll be testing Hal's tool on my test image and post those results tomorrow. In the mean time enjoy this very well written post!

If you want to contact Hal go to http://deer-run.com/~hal if you want train with Hal he is an excellent instructor with SANS http://www.sans.org/instructors/hal-pomeranz. Hal is an awesome forensicator and community resource who also is willing to 1099 to those of you like myself that run labs that are looking to extend our capabilities.

You can download the new tool has has made here: https://mega.co.nz/#!TsoTlSjR!BMz7BQqOhCeLGumWu51kaw4v_VFxd6UT3lyqu-ljUdc

With all that said, here is today's guest post from Hal.

Hal Pomeranz, Deer Run Associates

One of the nice things about our little DFIR community is how researchers build off of each other’s work. I put together a tool for parsing mlocate.db files for a case I was working on. David Cowen and I had a conversation about it on his Forensic Lunch. David had some questions about whether we could find previous copies of the mlocate.db in unallocated blocks, and wrote several blog posts on the subject here on HECF blog. David’s work prompted me to do a little work of my own, and he was kind enough to let me share my findings on his blog.

Hunting mlocate.db Files

In Part 3 of the series, David suggested using block group information to find mlocate.db data in disk blocks. My thought was, since the mlocate.db files have such a clear start of file signature, we could use the sigfind tool from the Sleuthkit to find mlocate.db files more quickly.

# sigfind -b 4096 006D6C6F /dev/mapper/RD-var

Block size: 4096 Offset: 0 Signature: 6D6C6F

Block: 100736 (-)

Block: 141568 (+40832)

Block: 183808 (+42240)

Block: 232192 (+48384)

Block: 269312 (+37120)

Here I’m running sigfind against my own /var partition. “006D6C6F” is “mlo” in hex, the first four bytes of a mlocate.db file (sigfind only allows a max of 4-byte signatures). I’m telling sigfind to look for this signature at the start of each 4K block (“-b 4096”). As you can see, sigfind actually located five different candidate blocks.

What was interesting to me was the blocks are in multiple different block groups in the file system. As David suggested in Part 3, the EXT file system normally tries to place files in the same block group as their parent directory. But when the block group fills up, the file can be placed elsewhere on disk.

I wanted to make sure that these were all legitimate hits and not false-positives. So I used a couple of other Sleuthkit tools and a little Command-Line Kung Fu:

# for b in 100736 141568 183808 232192 269312; do

echo ===== $b;

blkstat /dev/mapper/RD-var $b | grep Allocated;

blkcat -h /dev/mapper/RD-var $b | head -1;

done

===== 100736

Not Allocated