::: success
# CSN Lab № 3 Assignment: Technological Communication
**Name: Khasan Abdurakhmanov**
:::

<center>

## TASK 1

</center>

> **1.a. Define the following briefly:**
> * Process
> * Daemon
> * System call
> * Client & Server
> * Peer to Peer

**Process**: A program that is currently running and includes all of its instructions and the current state of its resources.

**Daemon**: In computing, a daemon runs constantly in the background to handle service requests, often from remote processes. It either responds to the request or forwards it to another program or process when the operating system (OS) alerts it to a request.

**System Call**: A system call is an essential interface provided by the operating system. It allows user-level programs to seamlessly request a wide range of services, ranging from vital file operations to efficient network access.

**Client & Server**: In the world of computing, there are two essential players: the client and the server. The client, a program desiring services or resources, reaches out to the server, a program capable of delivering those sought-after services or resources.

**Peer-to-Peer**: Peer-to-peer networking is a revolutionary architectural design that empowers each node in the network to assume the roles of both a client and a server. This empowers decentralized communication and the seamless sharing of valuable resources.

> **1.b. List and briefly explain the different types of Unix system calls for IPC.**

*Types of Unix system calls for IPC include:*
* **Message queues** provide a convenient means of communication between processes through system calls.
* **Semaphores** are powerful system calls used to implement synchronization and mutual exclusion between processes.
* **Shared memory** is a set of system calls that enables multiple processes to simultaneously access the same memory region.

These system calls provide a way for processes to communicate and coordinate with one another in a Unix-based operating system.

> **1.c. Explain for at least 2 kernel architectures, how IPC is handled**

<center>

Figure 1: Structure of monolithic and microkernel-based operating systems, respectively
</center>

**In the monolithic kernel architecture**, **IPC** is handled through system calls provided by the kernel. Each **IPC** mechanism has its own set of system calls to manage the creation, use, and destruction of **IPC** objects. When a process wants to use **IPC**, it makes a system call to the kernel to create or access the desired **IPC** object. This approach can provide good performance due to the direct access to kernel resources, but can also lead to a larger and more complex kernel codebase.
**In the microkernel architecture**, IPC is handled differently. The kernel provides only the most basic system calls, such as memory management and process scheduling. All other services, including IPC, are implemented as user-level processes that communicate with one another through message passing. This approach allows for greater flexibility and modularity, but may also introduce additional overhead due to the need for inter-process communication.

<center>

## TASK 2
</center>

> **2.a. Define the various methods for Inter Process communication and provide advantages and disadvantages respectively**

<center>

Figure 2: Inter Process Communication
</center>

**IPC**, or **Inter Process Communication**, is the essential method that allows processes to effectively interact and exchange information with each other. Processes can communicate with each other to exchange data, harmonize their activities, or synchronize their execution.

**There are several methods for IPC. Some of the commonly used methods are as follows:**

1. **Pipes** - A pipe is a form of one-way communication that allows the output of one process to serve as the input of another process. Pipes can be either anonymous or named. Anonymous pipes are created by the operating system and can be used only between related processes, while named pipes can be used between unrelated processes.
<center>

Figure 3: Pipe

| Advantages | Disadvantages |
| --- | --- |
| Simple to use and implement | One-way communication only |
| Low overhead | Limited buffer size |
| Can be used for both related and unrelated processes | Can only be used for communication between two processes |

</center>

2. **Message queues** enable efficient communication between processes by facilitating the exchange of messages through a shared queue. Messages are placed on the queue by sending processes and retrieved by receiving processes.

<center>

Figure 4: Message Queues
</center>

| Advantages | Disadvantages |
| --- | --- |
| Allows multiple processes to communicate with one another | More complex to use and implement than pipes |
| Can be used for both related and unrelated processes | Requires the use of system calls to access the message queue |
| Supports both one-way and two-way communication | Limited message size |

3. **Shared Memory** - Shared memory is a form of inter-process communication that allows processes to access a common area of memory. Processes can read from and write to this memory area, enabling efficient data exchange.

<center>

Figure 5: Shared Memory
</center>

<center>

| Advantages | Disadvantages |
| --- | --- |
| Very fast, as data is shared directly between processes | Requires synchronization to avoid race conditions and other issues |
| Can be used for large amounts of data | Can be difficult to implement correctly |
| Can be more efficient than other IPC methods | Only works on a single system |

</center>

> **2.b. What IPC facilities are currently on your system? Show the current activity in them**

In process of writing this lab I was using a Windows OS in my laptop so, to see the IPC facilities in Windows you should follow these steps:
1. Press `Ctrl + Shift + Esc` to open the `Task Manager`.
2. Click on the `Performance` tab.
3. Click on the `Open Resource Monitor` link at the bottom.
4. In the `Resource Monitor` window, click on the `Memory` tab.
5. In the `System` section, you can see the current activity on the IPC facilities, including `Message Send`, `Message Receive`, `Semaphore`, and `Shared Memory`.

<center>

Figure 6: IPC facilities
</center>

> **2.c. Create two separate programs which implements inter process communication (between parent process and child process) using shared memory and pipes, using any programming language of your choice.**

:::info
<center>Shared Memory</center>
:::

<center>

Figure 7: Shared Memory Parent code

</center>

This is a **Java** program that demonstrates **inter-process communication** using shared memory. In this program, a parent process writes a value to a shared memory area and a child process reads the value from the same shared memory area.

The program starts by creating a **`RandomAccessFile`** object with the filename "shared_memory.bin" and the "rw" mode. This creates a file with read and write access at the specified location. Then, a **`FileChannel`** object is created from the **`RandomAccessFile`** object.

Next, the program allocates a buffer of size 1024 bytes using the **`ByteBuffer.allocate()`** method. The buffer is then converted to an **`IntBuffer`** using the **`asIntBuffer()`** method. The integer value 42 is stored in the first position of the **`IntBuffer`** using the **`put()`** method.

Finally, the program writes the contents of the buffer to the file channel using the **`write()`** method. The program then prints a message to indicate that the value was successfully written to shared memory.

<center>

Figure 8: Shared Memory Child code

</center>

The program reads a value from a shared memory area. The shared memory area is created by a parent process.

The program starts by creating a **`RandomAccessFile`** object with the filename "shared_memory.bin" and the "rw" mode. This creates a file with read and write access at the specified location. Then, a **`FileChannel`** object is created from the **`RandomAccessFile`** object.

Next, the program allocates a buffer of size 1024 bytes using the **`ByteBuffer.allocate()`** method. The buffer is then read from the file channel using the **`read()`** method. The buffer is then flipped to prepare it for reading. An **`IntBuffer`** is created from the buffer using the **`asIntBuffer()`** method. The integer value stored in the first position of the **`IntBuffer`** is retrieved using the **`get()`** method.

:::info
<center>Pipes</center>
:::

<center>

Figure 9: Pipes Parent code
<hr>

Figure 10: Pipes Child code

</center>

I have written a **Java** code that allows for **inter-process communication** using **pipes**. **PipesParent** represents the parent process, while **ChildProcess** represents the child process. PipesParent sends a message to ChildProcess using the pipe and patiently awaits a response. The ChildProcess is responsible for reading the message, sending a response back through the pipe, and printing the received message from PipesParent. Finally, PipesParent prints the response it received from ChildProcess.

**Video Process of Running programms:** [HERE](https://disk.yandex.ru/i/ZaTH5zfPjRnJ3g)

<center>

## TASK 3
</center>

> **This task will be done in a team of 2.
> 3.a. Define the following:
> bind shell [ use nc, & powershell to show a practical example with your teammate] reverse shell [ use nc, ncat, socat, powershell & powercat to show a practical example with your teammate]**

:::info
My teammate : Soh Moumbe Vanel
:::

I was trying to connect for the connection from Vanel on port 4444 I use the ncat tool
<center>

Figure 11: Try to connect on port 4444
</center>

We exchanged messages to ensure that our connection was established. Following that, we switched roles and I began listening on port 4444.
<center>

Figure 12: Listening on port 4444
</center>

Vanel generously granted me access to his shell, allowing me to explore his system and search for specific files. During my investigation, I even executed commands such as **whoami** and **hostname**.
<center>

Figure 13: Accessing to shell
</center>

We are experimenting with bash and I was eagerly awaiting a connection from **Vanel**.
<center>

Figure 14: Listening using bash
</center>
Vanel get access to my shell.

<center>

Figure 15:Listening using ncat
</center>

After that, we swapped roles and I gained access to his shell, allowing me to pleasantly surprise him. I want to fully grasp the level of danger that accompanies directly granting someone access. I successfully shut down his computer. :+1:

Some samples where we use powercat:
<center>

 



</center>

> **3.b. List and give short explanations on the shell types in linux.**

Here are some common shell types in Linux:

* **Bourne Shell (sh)**: The original Unix shell, which is simple and lightweight.
* **Bash (Bourne Again SHell)**: The most popular and widely used shell in Linux. This is an upgraded iteration of the Bourne Shell that comes with additional functionalities and enhancements.
* **C Shell (csh)**: A shell with a syntax similar to the C programming language. It includes features like command-line editing and history.
* **Korn Shell (ksh)**: A superset of the Bourne Shell with additional features inspired by the C Shell and the Bash Shell.
* **Z Shell (zsh)**: An extended shell that incorporates features from other shells, including command-line completion, spell correction, and improved scripting capabilities.
* **Fish Shell**: A user-friendly shell with a focus on simplicity and interactive use. It provides features like autosuggestion and a web-based configuration interface.

These are just a few examples of shell types in Linux. Each shell has its own features and advantages, and users can choose the one that best suits their needs and preferences.

> **3.c. What is netcat’s gaping security hole? Recreate and explain it.**

**Netcat**, also known as "**nc**", indeed has a specific security vulnerability related to its "**-e**" option when it is setuid root. This vulnerability exists because **netcat** is often packaged with setuid root permissions to allow all users to bind on privileged ports below **1024**.

When the "**-e**" option is enabled and netcat is setuid root, it executes the specified process as root. This means that any user can run any process as root, which poses a significant security risk. This scenario represents a gaping security hole.

On the other hand, if you run your own process and use pipes to connect it to netcat, the process does not run as root unless you have another means of elevating its privileges, such as sudo access.

It's important to note that this explanation focuses specifically on the vulnerability associated with the "**-e**" option and setuid root configuration in netcat. There may be other security considerations depending on the specific usage and configuration of netcat.

# References
1. https://serverfault.com/questions/237584/netcat-e-the-gaping-security-hole
2. https://superuser.com/questions/486496/how-do-i-exit-telnet
3. https://habr.com/ru/companies/ruvds/articles/544512/
4. https://itsecforu.ru/2022/03/15/%f0%9f%95%b5%ef%b8%8f%e2%80%8d%e2%99%82%ef%b8%8f-%d1%88%d0%bf%d0%b0%d1%80%d0%b3%d0%b0%d0%bb%d0%ba%d0%b0-%d0%bf%d0%be-%d0%be%d0%b1%d1%80%d0%b0%d1%82%d0%bd%d1%8b%d0%bc-%d1%88%d0%b5%d0%bb%d0%bb%d0%b0/
5. https://gist.github.com/egre55/c058744a4240af6515eb32b2d33fbed3