A Guest Account, a Reversible Cookie, and a Linux Box Called Venus

Inside a practical vulnerability assessment of The Planets: Venus — from network reconnaissance to authentication weaknesses and privilege escalation analysis.

Sometimes, a penetration test doesn't begin with a sophisticated exploit.

It begins with an open port.

Then an interesting directory appears. A weak password turns up. A cookie that looks meaningless reveals information after a little analysis. Eventually, the investigation moves beyond the web application and into the underlying Linux system.

That was the story behind my assessment of The Planets: Venus, an intentionally vulnerable machine available through VulnHub.

The objective was to examine the target, identify security weaknesses, understand their potential impact, and investigate whether the available access could lead to further privilege escalation.

What made this assessment interesting was the combination of weaknesses across different layers: exposed services, weak credentials, reversible cookie data, and a potential local privilege escalation path.

This article documents the investigation, the evidence, and the lessons that can be taken from it.

1. The Target and Assessment Scope

The target was The Planets: Venus, created by SirFlash and released on VulnHub on June 3, 2021.

It is an intermediate-level Linux lab designed for practical security testing.

The assessment was conducted in an isolated virtual environment. Testing was restricted to the designated lab machine.

The main objectives were:

• Identify exposed network services.
• Enumerate the web application.
• Investigate authentication mechanisms.
• Examine session and cookie handling.
• Perform local Linux enumeration.
• Identify potential privilege escalation opportunities.
• Document findings and recommend remediation.

Tools used

The investigation involved:

• Nmap: Network discovery and service identification.
• Dirb: Web directory enumeration.
• Hydra: Authentication testing.
• Burp Suite: HTTP traffic interception and cookie analysis.
• LinPEAS: Linux privilege escalation enumeration.

The tools were used to collect evidence and identify areas requiring further investigation. A tool finding alone was not treated as proof of a successful attack.

2. Reconnaissance: What Was Exposed?

I started with network reconnaissance using Nmap.

The objective was to identify which services were listening on the target and determine where further investigation might be useful.

The scan identified two primary open ports:

Port 22 — SSH

The target was running OpenSSH 8.5.

SSH provides remote administrative access, making authentication security particularly important.

Port 8080 — HTTP

The web service was identified as WSGIServer/0.2.

This service provided the first opportunity to investigate the application's exposed functionality.

At this stage, the results did not establish that either service was vulnerable. They simply identified the available attack surface.

That distinction is important: an open port is an observation, not automatically a vulnerability.

3. Web Enumeration: Finding the Administrative Path

Next, I moved to web directory enumeration using Dirb.

Directory enumeration helps identify application paths that may not be linked from the homepage or visible through normal browsing.

One interesting discovery was:

/admin

The administrative path became a useful starting point for investigating the application's authentication controls.

An exposed administrative URL is not necessarily a security vulnerability. Administrative interfaces can legitimately be accessible while still requiring strong authentication and appropriate authorization.

The next step was therefore to examine the authentication mechanism rather than assume the path itself represented a compromise.

4. Authentication Testing: Weak Credentials

I used Hydra to test the authentication mechanisms identified during the assessment.

The testing revealed the following credential combinations:

• guest:guest
• magellan:guest

These results highlighted a basic but significant security weakness: inadequate password security.

Weak or predictable credentials can make exposed authentication services much easier to compromise.

The presence of an SSH service also makes credential security especially important. If weak credentials are accepted by a remotely accessible service, an attacker may gain an initial foothold without exploiting a software vulnerability.

This is a useful reminder that security is not determined by software versions alone.

A system can run relatively recent software and still be exposed through poor authentication practices.

However, the investigation was not limited to passwords.

I also wanted to understand what information the application exposed after authentication.

5. Cookie Analysis: Encoding Is Not Encryption

This was one of the most interesting findings during the assessment.

I used Burp Suite to intercept HTTP traffic and inspect the application's cookie data.

An authentication-related cookie contained the following value:

Z3Vlc3Q6dGhyZmc=

The string initially looked like an arbitrary sequence of characters. However, it was Base64 encoded.

Decoding it produced:

guest:thrfg

The value still contained another transformation.

Applying ROT13 to thrfg produced:

guest

The resulting value was:

guest:guest

This demonstrated that the cookie data could be recovered through simple, reversible transformations.

Why does this matter?

Base64 is an encoding mechanism. ROT13 is a character substitution technique.

Neither provides cryptographic confidentiality.

If an application stores sensitive authentication information in a client-side cookie using only reversible encoding, anyone who obtains that cookie may be able to recover its contents.

The actual security impact depends on how the application uses the recovered information and whether an attacker can obtain or reuse the cookie.

The important finding here is that sensitive authentication-related data should not be protected by encoding alone.

What should a secure implementation do?

A better session management design should:

• Use unpredictable, cryptographically secure session identifiers.
• Keep sensitive authentication information on the server.
• Avoid placing plaintext credentials in client-side cookies.
• Set appropriate HttpOnly, Secure, and SameSite cookie attributes.
• Rotate session identifiers after authentication.
• Invalidate sessions when users log out or when security-sensitive account changes occur.
• Use HTTPS to protect cookies in transit.

The central lesson is simple:

If a security mechanism can be reversed without a secret key, it should not be treated as encryption.

6. Moving Beyond the Web Application

After examining the exposed services and authentication behavior, I moved to local Linux enumeration.

The purpose was to understand the underlying operating system and identify possible privilege escalation opportunities.

I used LinPEAS to inspect areas such as:

• Operating system and kernel information.
• Installed software and package versions.
• SUID and SGID binaries.
• File and directory permissions.
• Scheduled tasks.
• Environment configuration.
• Potentially vulnerable system components.

LinPEAS is useful because privilege escalation is rarely limited to one specific vulnerability. Misconfigured permissions, outdated packages, exposed credentials, and insecure scheduled tasks can all create opportunities.

One item identified during the assessment was a potential connection to CVE-2021–4034.

7. PwnKit: A Potential Privilege Escalation Path

CVE-2021–4034, commonly known as PwnKit, is a local privilege escalation vulnerability affecting pkexec, a component of Polkit.

Under vulnerable conditions, a local unprivileged user may be able to obtain elevated privileges.

This makes it relevant when investigating a Linux system after obtaining initial access.

However, identifying a possible PwnKit exposure is not the same as proving that the target is vulnerable.

To establish applicability, an assessor needs to verify details such as:

• The installed Polkit and pkexec versions.
• Whether the installed component is affected or patched.
• Whether the required local access conditions are met.
• Whether the vulnerability can be reproduced safely in the authorized environment.

The available assessment evidence identified CVE-2021–4034 as a potential privilege escalation avenue, but did not establish the exact vulnerable package version or demonstrate successful exploitation.

For that reason, I have classified it as a potential issue requiring verification.

I am deliberately not presenting it as confirmed root access.

In professional security reporting, a potential vulnerability and a successfully demonstrated exploit are two different things.

8. HTTP Security Headers

I also reviewed the web application's HTTP security configuration.

The assessment identified the absence of several commonly recommended security headers:

Content-Security-Policy (CSP)

CSP allows a website to restrict the sources from which scripts, styles, and other resources can be loaded. A properly designed policy can help reduce the impact of certain content injection attacks.

Strict-Transport-Security (HSTS)

HSTS instructs browsers to use HTTPS when communicating with a website. It should be configured when the application is correctly served over HTTPS.

X-Content-Type-Options

The nosniff directive helps prevent browsers from interpreting content as a different MIME type than the one declared by the server.

X-XSS-Protection

This is a legacy browser security header. Its filtering mechanism is deprecated or unsupported in modern browsers and should not be relied upon as a primary XSS defense.

Missing headers do not automatically establish that an application is exploitable. Their significance depends on the application, its content, and the security controls already in place.

Modern applications should prioritize secure coding practices, contextual output encoding, and an appropriately configured Content-Security-Policy.

9. Assessment Findings

The investigation identified several areas of concern.

Finding 1: Weak Authentication Credentials

The assessment identified weak credential combinations, including guest:guest and magellan:guest.

Security concern: Predictable credentials can allow unauthorized access to services that accept them.

Recommended remediation:

• Replace weak credentials with strong, unique passwords.
• Remove unnecessary default and guest accounts.
• Apply appropriate authentication controls.
• Monitor repeated authentication failures.
• Restrict remote access where possible.

Finding 2: Reversible Authentication-Related Cookie Data

The observed cookie value could be decoded using Base64 and ROT13.

Security concern: Reversible encoding does not provide confidentiality. Sensitive authentication information may be exposed if it is stored in this manner.

Recommended remediation:

• Use secure, server-managed sessions.
• Avoid storing passwords or equivalent secrets in cookies.
• Generate unpredictable session identifiers.
• Apply appropriate cookie security attributes.
• Protect sessions using HTTPS.

Finding 3: Administrative Path Discovery

The /admin path was discovered during directory enumeration.

Security concern: An administrative interface should have appropriate authentication and authorization controls. Path discovery alone does not prove unauthorized access.

Recommended remediation:

• Enforce authentication and authorization.
• Restrict administrative functionality to appropriate users.
• Apply rate limiting where appropriate.
• Avoid exposing unnecessary administrative functionality.

Finding 4: Potential PwnKit Exposure

LinPEAS identified CVE-2021–4034 as an area requiring further investigation.

Security concern: If the installed Polkit component is vulnerable and the required conditions are met, local privilege escalation may be possible.

Recommended remediation:

• Verify the installed package version.
• Apply the appropriate security update.
• Review local privilege boundaries.
• Reassess after patching.

Finding 5: Missing HTTP Security Headers

Several recommended browser security headers were absent.

Security concern: The application may lack additional browser-side protections.

Recommended remediation:

• Configure an appropriate Content-Security-Policy.
• Enable HSTS when HTTPS is correctly implemented.
• Set X-Content-Type-Options: nosniff
• Review the application for injection vulnerabilities and implement contextual output encoding.

10. What This Assessment Actually Demonstrates

The most useful lesson from Venus is not that one particular tool discovered a weakness.

It is how different security issues can exist across the same environment.

Weak credentials affect authentication.

Reversible cookie data affects session security.

An exposed administrative path creates an area that requires access-control review.

A potential local privilege escalation vulnerability raises questions about operating system patching.

Missing HTTP headers highlight opportunities to improve browser-side defenses.

These findings should be assessed individually, supported by evidence, and prioritized according to their actual impact.

They should not automatically be combined into a single attack chain unless the relationship between them has been demonstrated.

11. From Technical Findings to Professional Reporting

Finding a weakness is only one part of a vulnerability assessment.

A useful security report must explain:

• What was discovered?
• Where was it discovered?
• How was it verified?
• What evidence supports the finding?
• What could an attacker achieve?
• What conditions are required?
• How should the issue be fixed?
• How severe is the issue?

Severity scoring is another important part of this process.

The Common Vulnerability Scoring System (CVSS) provides a structured way to communicate the technical severity of vulnerabilities. However, assigning a score requires more than labeling something as High or Critical.

The score must be supported by the actual exploitation conditions and impact.

I cover this process in a separate guide:

Continue reading: From Vulnerability to Disclosure: How to Score, Report, and Responsibly Disclose Security Findings

Conclusion

The Venus assessment was a reminder that security weaknesses do not always appear as dramatic software exploits.

Sometimes, the problem is a weak password.

Sometimes, sensitive information is hidden behind encoding that anyone can reverse.

Sometimes, a system component deserves closer inspection because it may contain a known privilege escalation vulnerability.

The important part of security research is learning to distinguish what was observed, what was verified, and what remains a possibility.

A good assessment does not exaggerate its results.

It explains the evidence, describes the risk, and gives administrators a clear path toward remediation.

The objective isn't simply to find a way in. It's to understand why the system allowed it, prove what happened, and explain how to prevent it.

References and Further Reading

• VulnHub — The Planets: Venus
• CVE-2021–4034 — National Vulnerability Database
• LinPEAS — PEASS-ng
• Nmap Reference Guide
• Burp Suite Documentation
• OWASP — Session Management Cheat Sheet
• FIRST — Common Vulnerability Scoring System

Disclaimer: This assessment was conducted against an intentionally vulnerable virtual machine in an isolated lab environment for educational purposes. The findings are limited to the observations and evidence described in this article. They do not represent a claim of unauthorized access to a production system.