Third step - Exploitation

vulnerabilities101 exploitingavulnerabilityv2 vulnerabilitycapstone

Exploitation πŸ’₯ is the third step of the pentester activities. We attempt to exploit a vulnerability discovered during investigation.

Some activities are:

  • πŸ”‘ Brute forcing credentials
  • πŸ’€ Exploiting a known (unpatched) vulnerability
    • in a service
    • in an application
    • in a website/an api
    • ...
  • ...

πŸ“Œ The goal is to get remote access to the target.

You will usually look for an unpatched vulnerability, and try to exploit it to upload or run commands to create a remote shell.

Vulnerabilities can be categorized in 5 categories:

  • πŸͺΈ Operating System
  • πŸ”₯ Misconfigurations (Version Disclosure, Sensitive Data Exposure, Security Misconfigurations)
  • πŸ” Weak credentials
  • 😎 Logic flaws (Insecure Deserialization)
  • πŸ§‘ Human errors

Note that not all vulnerabilities are exploitable, and not all vulnerabilities have a public exploit to exploit them.

Remote shell βš“

shells_and_payloads introtoshells Reverse Shell

In CTFs, you will most of the time be able to get a remote shell access to the target, similarily to a SSH access. There is a need for a

  • server which is accepting connections (most likely the hacker host)
  • client which is connecting to the server (most likely the victim)

There are 3 kind of ways to get a remote shell:

➑️ To avoid alerting IDS, a bind/reverse shell should use a protocol that would not be suspected such as HTTPS (443).

☠️ Most of the time, bind/reverse shells are blocked by firewalls.

🐸 See msfvenom to generate shells, and msfconsole to catch them.

Most remote shells that we create are instable:

  • πŸ˜₯ you can't use commands requiring user input (ex: sudo)
  • πŸƒ You can't clear nor resize your terminal
  • πŸ¦₯ There is no auto-completion, you can't use arrows...
  • β›” CTRL+C kill the shell, not the command

We can use a wrapper for the client/server (the one on your machine) to make things really nice, or we can try to manually patch the shell.

Not every shell can be upgraded (test another client...). A wrapper, may be available both as client or server depending on what you do.

Vulnerability databases

Vulnerabilities identifiers

To identify and classify vulnerabilities, you can use:

  • πŸ“Œ CVE (Common Vulnerabilities and Exposures) is a dictionary of every known vulnerability. The format is CVE-YEAR-ID.

  • πŸ“ CWE (Common Weakness Enumeration) is a list of common weaknesses in applications, grouped in categories.

  • See also: CAPEC, ATT&CK, CCE, CPE

Vulnerability scoring

There are 2 well-known systems to rank vulnerabilities.

  • πŸ€ CVSS (Common Vulnerability Scoring System) which was released in 2005, and is free and open-source. It calculated from 3 factors: Base, Temporal, and Environmental. Only the base is shown for a CVE. Use the calculator to compute your company-specific value.

  • πŸ’΅ VPR (Vulnerability Priority Rating) is a modern way based on the risk for the organization that uses it. It ranges from 0 to 100.

Proof Of Concept

When a vulnerability is discovered, a proof of concept (PoC) may be written to demonstrate that the vulnerability is exploitable. As a pentester, you may look for them to exploit a vulnerability.

➑️ Use GitHub, GitLab, and Google to look for them...

There are many vulnerability databases. You should use 2-3 as they may have different information (community info, list of exploits...).

Use the Metasploit Framework to use pre-written exploits usually leading to an enhanced reverse shell called meterpreter.

Common vulnerabilities πŸͺ¦

Websites 🌍

Databases πŸ’°

Serialization πŸ§ͺ

Memory πŸ₯”

Common Failures

Identification and Authentication Failure πŸ”‘

  • The website does not prevent brute force
  • The website allows users to use weak passwords
  • The website does not encrypt passwords

Broken Access Control πŸ“­ (users can access files/URLs they shouldn't)

  • The principle of the least privilege is not applied correctly
  • Someone can use someone else token/ID to do something
  • A user can access "logged-only" pages/features without logging in

Injections πŸͺ€

  • There is insufficient or no validation at all
  • There is insufficient or no sanitization at all


Cryptographic Failures πŸ”“

  • The server is using clear text
  • The server allows/uses HTTP instead of HTTPS
  • The server uses a weak cryptographic algorithm

πŸ‘» To-do πŸ‘»

Stuff that I found, but never read/used yet.