Alex Thomas, Ghostlulz - Bug Bounty Playbook v1 (2019)

| echo “hi” | echo “bye” Windows & Linux P a g e | 201

|| echo “hi” || echo “bye” Windows & Linux Pipe the first
commands
; echo “hi”; echo “bye” Linux output into the
second
`Command` echo “hi ` echo “bye”`” Linux command
Runs the
$(Command) echo “hi $(echo”bye”)” Linux second
command only
if the first
command fails.
Run the first
command then
the second
command.
Run second
command
inside first
command.
Note those are
back tics NOT
single quotes
Run second
command
inside first
command.

Table 5: Command injection techniques

An example of each of these commands being ran can be found below. Note
these were ran on a Linux machine.

Ghostlulz AKA Alex Thomas

P a g e | 202

Figure 124: Command injection examples

If you suspect an application is vulnerable to command injection you can easily
test for this vulnerable using the above techniques. An example can be found
bellow:

Ghostlulz AKA Alex Thomas

P a g e | 203

Figure 125: Command injection request and response

As you can see, I injected the “echo hi” command and I received a response.
This is a very strong indicator that the application is vulnerable to command
injection. However, the vast majority of these bug are blind and you won’t see
any output making it harder to detect.
With blind command injection you can’t use the “echo” command to test for this
vulnerability as there is no output being displayed. You can attempt to ping,
perform DNS lookup, or make an HTTP request against your machine though.
Then you listen on your machine for a request from the target. If you get a
request then you know they are vulnerable to blind command injection. Note to

Ghostlulz AKA Alex Thomas

P a g e | 204
test for this you will need a public IP address so you can receive a call back from
the target server.

Conclusion

Command injection is an older vulnerability that I don’t find all that often any
more. If you do find this vulnerability it will most likely be blind command
injection. The impact of this vulnerability is critical as you can execute remote
commands on the server easily allowing you to do whatever you want.

Cross Site Web Socket Hijacking (CSWSH)

Introduction

It’s pretty rare for me to come across an application using web sockets but when
I do I almost always find cross site web socket hijacking (CSWSH). Web sockets
set up a full duplex communication channel allows use to both read and post
data. This vulnerability can be used to perform XSS, SQL injection, RCE, and
anything else.

Web Sockets

WebSocket is a computer communications protocol, providing full-duplex
communication channels over a single TCP connection. Full duplex means we
can both read and write to the connection. Applications that utilize web sockets

Ghostlulz AKA Alex Thomas

P a g e | 205
typically want a live two-way communication mechanism. For instance, a chat
application might use web sockets to send messages back and forth.

Figure 126: Web socket connection

As shown above the connection starts off with the web socket handshake AKA
an HTTP upgrade request. This is used to established the web socket
connection. An example web socket handshake is shown below:

Ghostlulz AKA Alex Thomas

P a g e | 206

Figure 127: Web socket handshake

After the handshake is established you can start sending and receiving
messaging from the application

CSWSH

Cross site web socket hijacking (CSWSH) is similar to CSRF because we utilize
the targets cookies to make requests. Also, like CSRF the target would have to
visit our malicious page while logged into the target site for this to work. The
major difference is instead of sending a POST request we initiate a web socket
connection. After the WebSocket connection is established we can do whatever
we want.
Suppose we have a web application with a live chat feature that uses web
sockets for communication.

Ghostlulz AKA Alex Thomas

P a g e | 207

Figure 128: Live chat using web sockets

The first thing you want to do is examine the traffic in burp. Most people only
know how to use burp to test HTTP traffic but it can also handle web socket
traffic as shown below:

Ghostlulz AKA Alex Thomas

P a g e | 208

Figure 129: Burp web socket traffic

The next step is to create a POC to see if we can hijack a user’s WebSocket
connection. We can use the following website to test for the vulnerability:

● http://websocket.org/echo.html
To test for CSWSH you need to log into the target application as if you are a legit
user. Next you open a second tab in the same browser and attempt to create a
web socket connection. In this example I will be connecting to the live chat
application. If the endpoint is vulnerable, we will be able to create a web socket
connection using the user’s cookies.

Ghostlulz AKA Alex Thomas

P a g e | 209

Figure 130: CSWSH POC website

As you can see in the above image, I was able to initiate a web socket
connection using the users cookies. This is what makes it so similar to CSRF. A
real would attack would require a user to visit a malicious site while logged in to
the vulnerable application. The malicious site could then use the users cookies to
establish a web socket connection and send messages on behalf of the user.

The site also contains some POC code if you need to make any modification. It is
always a good idea to submit POC code when submitting a bounty.

<!DOCTYPE html>
<meta charset="utf-8" />
<title>WebSocket Test</title>
<script language="JavaScript" type="text/JavaScript">
var wsUri = "wss://echo.websocket.org/";
var output;
function init()
{

Ghostlulz AKA Alex Thomas

P a g e | 210

output = document.getElementById("output");
testWebSocket();
}

function testWebSocket()
{

websocket = new WebSocket(wsUri);
websocket.onopen = function(evt) { onOpen(evt) };
websocket.onclose = function(evt) { onClose(evt) };
websocket.onmessage = function(evt) { onMessage(evt) };
websocket.onerror = function(evt) { onError(evt) };
}

function onOpen(evt)
{

writeToScreen("CONNECTED");
doSend("WebSocket rocks");
}

function onClose(evt)
{

writeToScreen("DISCONNECTED");
}

function onMessage(evt)
{

writeToScreen('<span style="color: blue;">RESPONSE: ' + evt.data+'</span>');
websocket.close();
}

function onError(evt)
{

writeToScreen('<span style="color: red;">ERROR:</span> ' + evt.data);
}

function doSend(message)
{

writeToScreen("SENT: " + message);
websocket.send(message);
}

function writeToScreen(message)
{

var pre = document.createElement("p");
pre.style.wordWrap = "break-word";
pre.innerHTML = message;
output.appendChild(pre);
}

window.addEventListener("load", init, false);

</script>

<h2>WebSocket Test</h2>

<div id="output"></div>

Figure 131: CSWSH POC code

Ghostlulz AKA Alex Thomas

P a g e | 211
I have personally used this vulnerability to exploit quite a few applications. One of
the instances allowed me to completely take over users machines as the web
socket connection was being used to send shell commands to a remote server.
This allowed me to gain remote code execution (RCE).

Conclusion

You won’t run into applications using web sockets all that much but when you do
this is a great vulnerability to test for. Most developers and bug bounty hunters
don’t even know what this vulnerability. Like CSRF this is an attack on the end
users and can be used to establish a web socket connection while masquerading
as the victim.

Summary

This section only covered a small number of OWASP type vulnerabilities, there
are many more. The most popular vulnerability found is probably XSS. Almost
every application seems to contain XSS and the payout for the vulnerability can
be anywhere from $50 to $1000 depending on the impact and the company.
Another common vulnerability is SQL injection. This has been around forever and
will probably stay on the OWASP top 10 forever. CSRF is another vulnerability I
seem to find all the time. Most of the time I find this in the change email
functionality of a website which allows me to change a user’s email. From there
you could issue a password reset to gain account take over. SSRF seems to be
a lesser known vulnerability but I still find this fairly often as well. There are so
many vulnerabilities that I would really need to write a second book.

Ghostlulz AKA Alex Thomas

P a g e | 212

Ghostlulz AKA Alex Thomas