Introduction

Recently, a friend of mine (from outside the United States) had a third party make them a website for eCommerce sales and blogging. Because of this, they wanted me to do a quick review of the security of the application. After reviewing the account handling on the application I determined that the Password Reset functionality was the worst implementation ever made. If you can think of an issue I bet this had it... Below, we will be going into what went wrong and how to find these types of issues yourself.

Back to the Basics

If accounts exists on a website there are some basic features of it:

• Create Account
• Login
• Forgot Password/ Password Reset
• Update Account
• Delete Account
• View Account

If any of these is done in insecure way, major havoc can occur. In this blog post, we will be paying special attention to the Password Reset functionality of a website and how it can go wrong.

Basic Flow of Password Reset

What do you do if a user forgets their password? Well, you want them to be able to login, but you still want to make sure that it is the correct user. So, it is time to rest their password.

Generally, a users account is tied to an email. With this, the website can send this users email a magic link. This magic link deems that the user is trusted and will allow them to change the password.

This research was done by myself a while back and just got posted on my companies blog. Even though I generally post pwn or lower level articles on this blog, I am also into web application security and dive into the other things in my free time.

This research article is about securely routing requests in different web frameworks, such as Django, Flask, Ruby on Rails and more. The major consequence of insecurely routing pages is a CSRF bypass, as only particular HTTP methods are protected by CSRF. Overall, the research turned up some interesting results! So, I highly recommend taking a read in order to learn how to securely route requests in the most popular backend web frameworks.

The link for the article can be found on Security Innovation's website. Or, click here for the full article.

Introduction

On May 21st 2020, Checkpoint Research released a post that detailed the results of a security patch to multiple variations of Malloc, including the Malloc used in GLibC. This patch attempts to fix the inherit insecurities within singly linked lists being used as a bin data structure. In this article, I will be diving into how the security patches work and what this actually means for binary exploitation. For this specific article, we will dive into the patches put into GLibC's Malloc. However, the concepts of the mitigations will directly apply to all other versions of Malloc (just not the specific implementation details).

GLibC Malloc

In order to understand the rest of the article, a primer on the data structures used within GLibC's Malloc is required. For the purpose of this article there are two main data structures: chunks and bins.

Chunks

Chunks are the main object that users interact with. There are two main states to a chunk: allocated and free. The following picture demonstrates a free chunk:

The first field is the size of the previous chunk (prev_size). This is only used if the previous chunk is free. The second field is the chunk size. The chunk size represents the size of the data of the chunk and the metadata about the chunk (the first 3 bits of the size).

On a free chunk, the third field is used in order to store a pointer to other freed chunks. This field is known as the forward pointer or the Fd field. The fourth field is exactly the same, except that it stores a backwards pointer or bk.

Hey, this is Maxwell Dulin. Today, I wanted to discuss a fascinating spectacle! The binary exploiters of the world are trying to run a car with a half broken engine, 3 wheels and a destroyed windshield. What does this actually mean? We are trying to keep the program running just long enough for the ability to run arbitrary code.

Alright, enough of the metaphors... In general, heap exploitation is about corrupting the metadata of the heap (dynamic memory management) data structures in a particular way that allows for overwriting values that we should not be able to control. This article expects a basic understanding of heap exploitation. All of the basic data structures that re needed for this exploit will be explained in this article; but, for more information, I recommend reading this ebook.

This article is about the newly discovered House of Husk. This is a heap exploitation technique that can be leveraged in order to gain arbitrary code execution in GLibC. This is another one of these primitives, which eventually leads to code execution. I wanted to explain the inner workings of this technique, with a step-by-step guide on how to use it.

Top Down

First, we will discuss how this attack works at a high level. Then, dive into the technical details of how it actually works. In GLibC, it is possible to create custom format format string operations. These operators are then ran inside of GLibC. What would happen if we could somehow overwrite one of our function pointers with some method? This is the basis of the House of Husk.

In order to make this possible, there are four main steps:

1. Allocations
2. Unsorted Bin Attack
3. Freeing Spree
4. Printf Execution

In a nutshell, here is what the following does... The unsorted bin attack is used in order to allow for arbitrary writing of heap pointers into LibC (beyond the fastbin memory location). Then, by freeing chunks of specially chosen sizes, we can overwrite pointers within GLibC that are used for custom format string operations. Finally, we execute the format string in order to gain control of the program.

Hey all, I am Maxwell Dulin (also go by Strikeout). I am a Security Consultant in Seattle who graduated from college a little less than a year go. I play with the OpenToAll CTF team, which has a fantastic community! The Slack channel is a great place to ask questions about any field with lots of smart people to answer. Additionally, we have an internal Wargame site that is awesome for learning! Finally, this is Open To All , meaning that you (yes you!) can join. For more information, go to our registration site: here.

Overview

This challenge was part of the 2020 Auburn CTF. This was a high (965) point pwnable challenge. The pwnable is an online school system. The challenge had the following options:

• help
• attend <class>
• study <class>
• list
• stats
• grades
• quit

Additionally, there are two allowed classes: CompSci and Algebra.

Binary/Env

This was a 32-bit binary, which had all but PIE disabled. So, the binary had no stack canaries and executable stack(Nx). Additionally, the challenge mentions that ASLR is turned off. Because NX is turned off, we can expect to write some shellcode in the challenge.

Reversing

I popped this into Ghidra and went to work! This program was quite weird to reverse. With jump tables all over the place this was not a trivial program to understand. Understanding all of the jump tables and misdirection was not needed in order to get the flag. But, I went down several rabbit holes before eventually finding the solution.

The first thing I always look for is the main function in order to see all of my options. I rename all of the functions and variables in order to make reversing easier.

The first major reversing discovery that I found was that there was a third class: Hacker. Studying for this class worked exactly the same as before. However, the attend option provided a significantly different option compared to the other classes. This code crashes before returning, but leaks a Stack address for us prior to crashing.