Your App Center List Is Not a Security Audit

The App Center is a package browser, not an inventory. It does not represent a security audit of a system's installed packages. While it shows the two sources it manages—the Ubuntu archive and the Snap Store—it overlooks all other potential attack vectors. For a comprehensive security assessment, additional steps are necessary.

To investigate a system's security posture, first understand that "Updated 9 years ago" does not indicate neglect. Instead, it refers to the package version date. The listed packages—URW)++ Core Font Set 20200910-8, TeXInfo, and BRLTTY—are dependencies that were required when other packages were installed, not evidence of security vulnerabilities.

Gray placeholder icons in the App Center do not signify unsigned packages. They merely indicate that no AppStream metadata or .desktop file is associated with the library. Most of these libraries are legitimate dependencies pulled in by other packages, with only a few being benign findings. However, these observations do not provide any insight into the integrity of the software.

To verify the integrity of installed packages, use Snap publishers verification. Run the following command:

```

snap list for s in $(snap list | awk 'NR==1{print $1}') ; do snap info $s | grep -E '^(name|publisher)'; done

```

This will display the publisher column for each snap installed on the system. Canonical, GNOME runtimes, and trusted community maintainers will have verified publishers (marked with a ✓). If any snap has an unmarked publisher, it should be scrutinized further, as this could indicate a potential security risk. In this case, all 21 snaps on the system were marked by verified publishers, indicating no immediate cause for concern.

Another critical step is to check for third-party APT repositories. Run the following command:

```

grep -rhE '^deb' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

```

This command searches for any lines beginning with "deb" in the APT configuration files. Seven repositories were found, all signed with dedicated keys, which is the modern, correct form for securing APT repositories. If any repositories are unmarked, they should be reviewed and fixed. In this scenario, six of the repositories were familiar and trustworthy, while one was unfamiliar. Further verification of the URL and the corresponding signing key was necessary to confirm its authenticity.

Verifying the signing key of recognized repositories is crucial. Use the following command to display the key's fingerprint:

```

gpg --show-keys --fingerprint /etc/apt/keyrings/repo-key.gpg

```

Compare the fingerprint against the published fingerprint to ensure they match. In this case, a full-length match was found, confirming that Google's Artifact Registry Repository Signer published the Antigravity repository. However, it's important to note that this fingerprint only proves that Google Artifact Registry published the repository, not that the Antigravity team did.

The trust boundary lies in the repository path, so verifying both the key and the repository path is essential for comprehensive security assurance.

To check for binary integrity, install debsums and run the following command:

```

sudo apt install debsums

sudo debsums -s

```

debsums computes the checksum of every file installed from a .deb package and compares it against what the package shipped. If any checksum mismatches are found, it indicates that a binary or library has been modified, potentially by malware. In the case study, three missing .desktop files were discovered, which accounted for the gray placeholder icons in the App Center.

These missing files were likely the result of an app-grid cleanup, rather than any malicious activity. Running this command provides a definitive answer to the malware question, as any file modifications would have been flagged.

Lastly, review running services and potential persistence mechanisms. Use the following commands:

```

sudo systemctl list-units --type=service --state=running

ls -la ~/.config/autostart/

ls -la /etc/systemd/system/

```

This will provide a list of all running services and any autostart entries. In this example, 34 services were running, including Docker, containerd, Cloudflare warp service, ClamAV daemon, and various GNOME and systemd components. The autostart directory contained only two entries, both created by the user. Additionally, it was observed that certain system services, like avahi-daemon.service, cups.service, and libvirtd.service, were absent from the system.

Proper verification of these services ensures that no unauthorized or malicious persistence mechanisms have been installed on the system.

By following these guidelines, you can conduct a thorough security audit of a system, going beyond the apparent simplicity of an App Center list. This approach ensures that you cover all potential attack vectors, from package integrity to service persistence, providing a comprehensive assessment of the system's security posture.