My name is Maxwell "ꓘ" Dulin and I am a Senior Security Engineer who attempts to hack everything under the sun; from web applications to garage doors. Recently, an article about a SQL injection technique that exists solely in the main MySQL NodeJS library was released. This technique works by injecting a JSON object into a parameterized query that expects a string. While looking at the payload for this exploit, I wondered two things:

• Why does this attack work with a nested object?
• Is my website using NodeJs vulnerable to this attack?

In this post, we will answer both of these questions. First, we will find the root cause of this bug within the mysqljs library. Second, we will walk through the exploitation of this vulnerability on my personal blog (this site!). NOTE: Please do not attack my site, as the vulnerability has already been patched.

Bypassing Escape Functions in mysqljs

The authors of the article did a wonderful job at explaining the attack and including a live demo. I will only be giving a quick summary of the initial part of the article; but, I encourage you to read the article and test out this bug yourself at the live demo from the post.

The article begins with a very simple NodeJs Express setup for a login endpoint; an image of this is shown in Figure 1. On lines 3 and 4, the username and password fields are put into local variables to be used in a query later. On lines 6-8, there is a classic SQL query that validates the user attempting to login matches the password on lines. This uses a parameterized query to add the request supplied username and password to prevent a SQL Injection.

The author then pulls out an exploit payload that looks nonsensical:

data = {
  "username": "admin",
  "password": {
    "password": 1
  }
};

The JSON object has two fields that are used: username and password. The object does not have a string for the password field though; instead, it has another object inside of the field. With the code snippet shown above and mysqljs as the library of choice for querying, the object shown above will completely bypass the authentication mechanism! To me, this seemed impossible since the code is using parameterized queries to prevent SQL injection. Therefore, I had to understand why this exploit works the way it does.

Why Does This Happen?

After going through the demo website for this, the reason for this bypass occurring still did not make sense to me. All I understood was that putting a very specific object bypassed the authentication flow. Why does putting a JSON object with very specific parameters bypass the authentication? In particular, what is the query parsing doing here? Since I was not satisfied with just knowing about the vulnerability, I decided to open up the source code to truly understand why this occurs.

Introduction

After seeing my hero Samy Kamkar's research into garage door remotes called Open Sesame, I got interested in software defined radios (SDRs). In particular, I was curious what other items would be vulnerable to replay, interception and other types of attacks. Leading up to some other research (stay tuned!), I dove into my childhood home's electronic garage door opener. This garage door remote is labeled as the Sears Craftsman 139.53708 Garage Door Remote, which was originally manufactured 30+ years ago. Even though this device is old, this post is more about reversing radio signals and recreating the signal ourselves.

In this article, we will dive into the reverse engineering of wireless signals with off the shelf tools and how to launch practical attacks against these wireless systems.

How Does This System Work?

Remote

The remote has 9 DIP switches. These are used to configure the secret code that is transmitted to unlock the garage door. Each of these switches has three options: +, 0 and -. Most data transmission is binary in nature. This was interesting since we had a ternary code as opposed to the traditional binary code. All of this information can be seen in Figure 1 above.

The main schematic for this alluded me for a long time, where I initially thought that the main chip was ADC from the P8416. However, with inquiries from Gene Berkowitz and Scott LaBombard after I initially posting this article, I learned the true nature of the device! P8416 indicates the production code: China (P) and the 16th week of 1984. Then, the actual chip part is 125C20. The naming conventions on chips are new to me but I was linked a good resource at chipdocs, which helps quite a bit.

The 125CXXX chip is really a ternary encoder that takes input from the DIP switches. Since the product is a proprietary and owned by Chamberlain, then sold by Sears, there are no public datasheets for this exact product. However, since this is a family of products, there is a schematic for a generic Chamberlain garage door remote that should be fairly similar to our remote. The FCC ID on our target remote returns no information, sadly. Sometimes, venturing off into similar products can be useful for reverse engineering your target if there is no documentation on your target. Good to know!

Syncing

The receiver (door opener) has a button on the side of it. This button is used to sync the receiver with the remote. To reprogram the receiver, this button needs to be pressed then we send our new code from the remote. At this point, the code has been changed on the garage door receiver. This is interesting to me since I expected for a similar DIP switch to be on the receiver as the transmitter but this was not the case.

Signal Analysis

When analyzing signals, there are many components of a signal to consider. Three of the most important are mentioned below:

• Frequency
• Modulation
• Encoding scheme for bits

Introduction

Exploiting heap based vulnerabilities tends to be difficult, complex and requires a deep knowledge of the library itself. As years go by, new techniques are discovered for exploiting the allocator, as well as changes being made to make the allocator more secure. The never ending cat-and-mouse game that is cybersecurity.

In 2020, several techniques were published in the House of IO that required rare primitives to achieve. Among these, the House of IO - Underflow allowed for the returning of arbitrary memory addresses from Malloc with a buffer underflow vulnerability. This could even bypass pointer mangling/encryption! In his article, we will discuss a primitive improvement to the House of IO - Underflow that may be useful in real world exploitation: a single buffer overflow with careful heap alignment. A proof of concept can be found at House of IO - Heap Reuse if you would like to follow along.

Chunks

Chunks are the main object that a developer interacts with when using Malloc. Besides the physical size of the memory, there are many other fields with the chunk:

• prev_size: The size of the previous chunk. This section is only used when the previous chunk is free.
• size: The size of the memory being given back to the user program. The first three bits include metadata of the chunk: prev_inuse (if the previous chunk is in use), mmap (is the allocated chunk using mmap) and n on-main arena (if the chunk is in a non-main arena).
• Fd: When chunks are free, they are stored within a linked list. The Fd is the forward pointer in the linked list when a chunk is in a bin. This field is only used when a chunk is free.
• Bk: Backward pointer in the linked list for when a chunk is in a bin. This field is only used when a chunk is free.

The root cause of many vulnerabilities are from the mishandling of numbers. The standard int type can go from 0x7FFFFFFF all the way to -0x80000000 (notice the negative) with an integer overflow. Or, it can be truncated and change the number from positive to negative. Integers can be a nightmare in C and have caused many memory corruption vulnerabilities over the years.

Recently quite a few findings have caught my attention that fall into the integer bug classes. A few to call out are the integer truncation bug in the Linux kernel found by Qualys, the signedness conversion bug (issue 2) in the BSD hypervisor by GHSL and an integer overflow in the Kindle on a buffer allocation size found by Checkpoint. Then, my hacking buddy seiraib found an integer overflow bug fuzzing but we could not find where the overflow actually occurred at. All of this got me wondering: "Can these bug classes be discovered at compilation or immediately crash at runtime?"

Yes, yes they can! GCC and Clang have compilation flags to find several bug classes at compile time. Additionally, there are some runtime protections that can cause crashes to make root causing MUCH easier. This blog post is about finding vulnerabilities via compiler warnings and dynamic instrumentation. All of the source code snippets with extra examples can be found at mdulin2/integer_ compilation_flags.

Bug Classes

The goal is to change a number in a way that the program does not expect to cause memory corruption down the road. There are three number (but mainly integer) vulnerability classes in C that will be focused on:

• Overflow/underflow: Integers will simply wrap around if you go past the maximum or minimum value of the type in C. For instance, an overflow of a signed integer would go from 0x7FFFFFFF all the way to -0x80000000. The underflow goes in the opposite direction and happens when subtracting values instead.
• Truncation: Shrinking the storage capacity of a number. For instance, going from uint64_t to uint32_t would cut the storage capacity of the number in half. This has the potential to drastically change the value and signedness of the number.
• Signedness conversion: Numbers are either signed and unsigned (unsigned int and int for example). Going between these can have terrible consequences when converting from a negative signed number to an unsigned number or a very large unsigned number to a signed number. For instance, an unsigned integer of 0xFFFFFFFF converted to a signed integer would be -1 instead of a very large number.

The web is full of user reviewed rating websites that we trust with our lives every day. Glassdoor allows us to see inside a company; Amazon reviews allow us to see what it is like to own a product; Yelp for restaurants... this is just the world that we live in.

But, what if you could sway the rating system? On Yelp, you could make a restaurant appear at the top of every search! Like in a dream, everyone would flock to your restaurant. Or, you could kill a competitors business, making yours look more appealing. This would be an amazing weapon to gain a competitive advantage on the rest of the market. In this article, we discuss a business logic vulnerability that was able to skew the ratings systems on a popular location-based ratings site.

Vulnerability - The Case of Bad Input Validation

Juice Shop Version

The company asked to remain anonymous and to have no screenshots of the bug. So, we will get creative! To demo the bug, we will look at Juice Shop; the bug from OWASP Juice Shop is essentially the same as the real site. For those not familiar, OWASP Juice Shop is an intentionally vulnerable site from the Open Web Application Security Project (OWASP). In fact, this was one of my main resources for learning prior to becoming a security engineer at my current company.

OWASP Juice Shop has a customer feedback functionality, which is normal for many applications. This ratings system is on a scale of 1-5 where a sliding scale can be set to choose the rating. On the backend request, this is simply an integer being sent. What if we changed this to something that is NOT 1,2,3,4 or 5? The request for the customer feedback is shown in Figure 1 below within Burp.

Figure 1: -100 Rating

By changing the rating to a non-expected value, such as -100 shown in Figure 1, we can drastically affect the overall customer ratings! This works in either the positive or negative direction. The challenge for this is titled give a devastating zero-star feedback to the store. On Juice Shop, we can change the rating value to be set to 0 in order to solve this challenge. Now, this website is meant to be vulnerable. Does this bug look the same on a real and in production website?

The Actual Site

The target website stores information about a location and allows for ratings this specific type of location. When giving a rating on the user interface, the options are given as a collection of 5 stars. The user highlights the amount of stars for the rating (1-5) and this is the value sent to the backend. As a result, it is not possible to enter a value other than 1-5 in the UI. As demonstrated in the example above, this is not enough though! Client-side restrictions are a futile security protection.

This seemed like fertile testing ground to go through, as I remembered the Juice Shop example from years ago. I used a web app pentesters best friend Burp to proxy the request and altered the rating to be -5000. But, this failed with a 500 error, which surprised me, since the application had never thrown me a 500 error like this before. After trying increasingly smaller negative numbers, to my surprise, -500 worked! I did the same thing in the positive direction with positive 500 and this worked as well. It appears they had some sanity checking on the values but not enough. What does this actually mean though?

Impact of Bug

Most rating systems are calculated by taking the average. This average is then used everywhere on the website for finding locations to visit. In fact, this overall rating is the most important descriptor about a location to decide if people do or do not go somewhere. Being able to inject a rating of -500 or +500 would drastically raise the average rating (even past 5 stars) or drop the rating of the location significantly. Raising it could make the location extremely popular while dropping it would make the location unlikely to be visited.

In a community that relies upon the reviews of others, being able to have this large of a stake in the voting on each location allows for the rise in popularity or the downfall of a place by a single person. This compromises the people sourced system entirely; eventually, this could break the trust of the users and force them to use other services. Luckily, the fix for the bug is simple: only allow values from 1-5 on the backend.

Disclosure

From previous experiences, I am nervous when trying to report security vulnerabilities. As a result, I have learned to be very kind and come from the perspective of "I found this bad bug. Please let me help you fix it." If you go in guns blazing and attacking the service team with comments about how crappy the software is and how great of a hacker you are, then you are unlikely to have a good response with the team (we've all made this mistake before). Keep this in mind when reporting to companies or people without a formal bug disclosure program especially. Yes, I know testing on these sites is technically illegal; I hope that people see the good in us though, as the testing is done in good faith. In this particular case, the company had the best response I have ever received!

My initial communication with the company was to a senior engineer over LinkedIn. The company did not have a security email so this was my best course of action. Eventually, a support ticket from the support@company.com got back to me as well but hours after the initial contact with the engineer on LinkedIn.

Since the initial LinkedIn message only allows for only 300 characters, after the initial connection I sent a longer message explaining the details of the bug with a few screenshots. In particular, I sent a screenshot with the overall rating for the location being 0 stars and the next one being 9 stars, even though the limit is 5 stars. At this point, the engineer replied Oh wow, that's pretty bad. we are on it. " The engineering team fixed the bug immediately.

After this, the CTO of the company added me on LinkedIn and thanked me for the finding and responsible disclosure. The CTO let me know that a security engineering position would be opening up soon; they wanted me on the short list for the job once the position opened up. Additionally, they offered me a lifetime membership to the application! Considering I use the application quite a lot, this was very exciting for me :) A huge shoutout to the engineer and CTO for the amazing response to the finding. This makes me happy to find bugs and report them to make the internet a safer place.

Conclusion

Vulnerabilities are not always complicated injection attacks. Commonly, they are centered around how the logic of the site; these bugs are undetectable by scanners. Although throwing <script>alert(1)</script> may find some XSS, lots of bugs require an understanding of the applications logic and expected functionality. Prior to throwing random inputs everywhere, ensure that you understanding the business-logic of the application in test.

Feel free to reach out to me (contact information is in the footer) if you have any questions or comments about this article. Cheers from Maxwell "ꓘ"Dulin.