Home > Linux

Installed Packages

Enumerating installed packages is a critical part of Linux pentesting because outdated software, vulnerable libraries, misconfigured services, and unnecessary packages expand the attack surface. Every distribution uses a package manager that maintains versions, dependencies, update history, and security patches. A single outdated package can expose the entire system to remote code execution, privilege escalation, or lateral movement. This chapter covers complete hands-on, practical enumeration and exploitation techniques for installed packages across major Linux distributions.

Why Installed Package Enumeration Matters

Attackers and pentesters analyze installed packages to:

  • Identify outdated or vulnerable software

  • Map package versions to known CVEs

  • Discover unnecessary services that broaden the attack surface

  • Analyze dependencies for hidden vulnerabilities

  • Check whether security-critical packages are missing

  • Identify misconfigured or custom-built software

  • Detect signs of intrusion (rogue packages, tampered binaries)

Package enumeration directly supports vulnerability analysis and exploit selection.

Identifying Installed Packages on Debian/Ubuntu (APT)

List all installed packages:

dpkg -l

Filter for specific packages:

dpkg -l | grep openssh

Show package details:

apt show <package>

Check version and repository source:

apt-cache policy <package>

Find outdated packages:

apt list --upgradable

Example:

apt list --upgradable | grep linux-image

This helps identify vulnerable kernels or unpatched services.

Practical Example: Finding a Vulnerable Apache Version

Check Apache version:

apache2 -v

Check installed package:

dpkg -l | grep apache2

If output shows something like:

2.4.29-1ubuntu4

You can research CVEs for that exact version.

Identifying Installed Packages on Red Hat/CentOS/Fedora (RPM)

Enumerate packages:

rpm -qa

Search for specific software:

rpm -qa | grep ssh

Detailed package info:

rpm -qi <package>

Check installed and available versions:

dnf list installed
dnf list available <package>

List updates:

dnf check-update

Find vulnerable or outdated services easily using version numbers.

Practical Example: Detecting Vulnerable Nginx on CentOS

rpm -qa | grep nginx

Output might look like:

nginx-1.16.1-1.el7.x86_64

Check for known CVEs based on this version.

Enumerating Installed Services on Arch Linux (Pacman)

List installed packages:

pacman -Q

Search for packages:

pacman -Qs <name>

Show outdated packages:

pacman -Qu

This helps identify attack paths unique to rolling-release systems.

Enumerating Packages on Alpine Linux

Alpine uses apk.

List packages:

apk info

Search:

apk info | grep ssh

Show details:

apk info -a <package>

Alpine is common in containers, making package enumeration critical for container breakout and supply chain analysis.

Enumerating Python Packages (Virtualenv & System)

Systems often rely on Python applications. Outdated Python libraries can be exploited.

System-wide:

pip list

Virtual environments:

source venv/bin/activate
pip list

Look for risky packages such as:

  • Flask

  • Django

  • Paramiko

  • Requests

These may contain known vulnerabilities.

Enumerating Node.js Packages

List global modules:

npm -g list --depth=0

Local project modules:

npm list --depth=0

Look for:

  • Express

  • Sequelize

  • Axios

  • CI/CD tools

Node packages often expose RCE vulnerabilities.

Enumerating PHP Modules

Check installed modules:

php -m

Find installed PHP packages:

dpkg -l | grep php
rpm -qa | grep php

PHP vulnerabilities frequently lead to code execution.

Enumerating System Libraries

List installed libraries:

ls /usr/lib
ls /lib

Check versioned libraries (useful for 0-day matching):

ls /usr/lib/x86_64-linux-gnu | grep ssl

Example:

libssl.so.1.1

Knowing library versions helps exploit OpenSSL, libc, and SSH-related vulnerabilities.

Checking for Custom-Built or Non-Standard Software

List manually compiled software in /usr/local:

ls -la /usr/local/bin
ls -la /usr/local/sbin

Search for custom binaries:

find / -type f -perm -111 -exec ls -l {} \; 2>/dev/null | grep local

Hand-compiled software is often outdated and vulnerable.

Detecting Rogue or Malicious Packages

Check if packages were installed recently:

grep " install " /var/log/dpkg.log

or:

dnf history

Look for:

  • Unknown services

  • Suspicious binaries

  • Packages installed outside normal update cycles

This helps detect intrusions or persistence mechanisms.

Enumerating Services via Systemd

List systemd-managed packages/services:

systemctl list-unit-files --type=service
systemctl --type=service --state=running

Identify unnecessary or dangerous services such as:

  • FTP

  • Telnet

  • TFTP

  • NFS

  • SNMP

  • RPC services

These services expose major attack surfaces.

Mapping Installed Packages to CVEs (Practical Workflow)

Step 1: Export package list

Debian/Ubuntu:

dpkg -l > pkglist.txt

Red Hat:

rpm -qa > pkglist.txt

Step 2: Feed list into vulnerability scanners such as:

  • OpenVAS

  • Nessus

  • Lynis

  • Vulners API

  • Trivy

  • Grype

Step 3: Identify high-risk versions and misconfigurations.

Example:
If system has:

openssl 1.0.2

This version has severe vulnerabilities including Heartbleed timing issues depending on build.

Checking Shared Libraries for Hijack Vectors

Show libraries a binary uses:

ldd /usr/bin/sudo

Look for:

  • Missing libraries

  • Libraries in writable paths

  • Unexpected library injection points

Library hijacking is a powerful privilege escalation method.

Checking for Insecure Package Repositories

Debian-based repo list:

cat /etc/apt/sources.list
cat /etc/apt/sources.list.d/*

Look for:

  • HTTP repositories instead of HTTPS

  • Third-party mirrors

  • Old EOL (End of Life) distributions

EOL repositories mean no security patches.

Container Package Enumeration

For containers:

docker exec <id> dpkg -l
docker exec <id> apk info
docker exec <id> rpm -qa

Containers often ship outdated or minimal packages but still expose vulnerabilities.

Practical Exploitation Scenarios

Scenario 1: Outdated Apache

apache2 -v

Map version to RCE vulnerabilities like:

  • CVE-2019-0211

  • CVE-2021-41773

Scenario 2: Vulnerable OpenSSL Version

openssl version

Older versions are vulnerable to Heartbleed and MitM attacks.

Scenario 3: Writable Libraries for Privilege Escalation

If ldd shows a library in /tmp or a user-writable directory, replace it with a malicious .so file for instant root access.

Scenario 4: Old Kernel Packages

apt list --upgradable | grep linux-image

Old kernels often have privilege-escalation CVEs.

Intel Dump

  • Package enumeration reveals outdated or vulnerable software

  • APT, RPM, Pacman, and APK each provide tools to list installed versions

  • Specific applications like Apache, Nginx, PHP, Node, Python, and OpenSSL must be version-checked

  • List outdated packages using apt list --upgradable or dnf check-update

  • Check custom-built binaries in /usr/local/bin

  • Library enumeration with ldd detects hijack paths

  • Rogue package installs indicate backdoors

  • Map versions to CVEs with tools like searchsploit, Trivy, and Grype

  • Identify insecure repositories or EOL distributions

  • Combine package enumeration with process and user data to understand escalation paths

Give the next chapter title when ready.

HOME LEARN COMMUNITY DASHBOARD